Poprawne modele zawartości. Zarządzanie zmianami struktury.

1. Poprawne modele zawartości.Zarządzanie zmianami struktury.

2. XML a białe znaki • W modelu elementowym: • ignorowane, • służą jedynie zwiększeniu czytelności. • W modelu tekstowym/mieszanym: • stanowią część zawartości tekstowej. • Na granicy modeli: • ??? Poprawne modele zawartości. Zarządzanie zmianami struktury.

3. Model błędnej zawartości (1) <!ELEMENT hasło (pojęcie, #PCDATA)> <hasło><pojęcie>zombie</pojęcie>w religiach afrykańskich: osoba zmarła, która może ożyć dzięki magii</hasło> Równoważny model poprawny: <!ELEMENT hasło (pojęcie, znaczenie)> <!ELEMENT znaczenie (#PCDATA)> Poprawne modele zawartości. Zarządzanie zmianami struktury.

4. Model błędnej zawartości (2) <!ELEMENT znaczenie (#PCDATA | definicja)> <hasło><pojęcie>półpłaszczyzna domknięta</pojęcie><znaczenie><definicja>jedna z dwu części płaszczyzny, na które prosta L dzieli tę płaszczyznę, wraz z tą prostą</definicja></znaczenie></hasło> Równoważny model poprawny: <!ELEMENT znaczenie (treść | definicja)> <!ELEMENT treść (#PCDATA)> Poprawne modele zawartości. Zarządzanie zmianami struktury.

5. Model niejednoznaczny <!ELEMENT hasło (pojęcie, znaczenie?, etymologia?, znaczenie)> Równoważny model poprawny: <!ELEMENT hasło (pojęcie, ((znaczenie, (etymologia?, znaczenie)?) | (etymologia, znaczenie)))> Poprawne modele zawartości. Zarządzanie zmianami struktury.

6. Elementy w dowolnej kolejności (1) Konstrukcja SGML-owa: <!ELEMENT wielojęz - - (pol & ang)> Równoważny model poprawny: <!ELEMENT wielojęz ((pol, ang) | (ang, pol))> Poprawne modele zawartości. Zarządzanie zmianami struktury.

7. Elementy w dowolnej kolejności (2) Konstrukcja SGML-owa: <!ELEMENT wielojęz - - (pol & ang & niem)> Równoważny model poprawny: <!ELEMENT wielojęz ((pol, ((ang, niem) | (niem, ang))) | (ang, ((pol, niem) | (niem, pol))) | (niem, ((pol, ang) | (ang, pol))))> Poprawne modele zawartości. Zarządzanie zmianami struktury.

8. Zarządzanie zmianami w DTD • Problem: • niezbędna jest zmiana definicji języka: • zmieniająca się rzeczywistość, • uwarunkowania prawne, • nowe wymagania, • ... • posiadamy zasoby zgodne z aktualną wersją DTD, • jak uczynić zmianę kompatybilną wstecz? • Rozwiązanie: • nowy model musi być bardziej ogólny od dotychczasowego. Poprawne modele zawartości. Zarządzanie zmianami struktury.

9. Dozwolone zmiany w DTD (1) • Dodanie elementu opcjonalnego <!ELEMENT słownik (hasło, (znaczenie | definicja), etymologia?)* > • Zmiana krotności elementu: • z wymaganego na opcjonalny, • z jednokrotnego na powtarzalny. <!ELEMENT osoba (imię, nazwisko, adres*)> • Dodanie elementu do alternatywy: <!ELEMENT podróż (samochód | pociąg | samolot | rakieta)*> Poprawne modele zawartości. Zarządzanie zmianami struktury.

10. Dozwolone zmiany w DTD (2) • Dodanie atrybutu: • opcjonalnego, • z wartością domyślną, • #FIXED <!ATTLIST wiersz bialy (tak|nie) ”nie”> • Zmiana typu atrybutu: • z wymaganego lub #FIXED na opcjonalny lub z wartością domyślną, • z opcjonalnego na wartość domyślną i na odwrót. <!ATTLIST wiersz bialy (tak|nie) ”nie” ><!ATTLIST wiersz bialy (tak|nie) #IMPLIED> Poprawne modele zawartości. Zarządzanie zmianami struktury.

11. Jak zarządzać zmianami • Zmiany niekompatybilne wstecz – przykład: • dodanie elementu wymaganego. • Sposób postępowania w „żywym” systemie: • wprowadzamy zmianę kompatybilną wstecz (np. dodajemy element, ale opcjonalny), • instruujemy użytkowników o konieczności migracji do nowej struktury, • po dodaniu brakujących elementów (lub po upływie wyznaczonego czasu) – wprowadzenie zmiany docelowej. • Większe zmiany modelu: • deklarujemy osobny element z nowym modelem, • przez pewien czas dopuszczamy stary lub nowy model. Poprawne modele zawartości. Zarządzanie zmianami struktury.

12. Zmiany struktury a aplikacje • Typowa zależność między treścią programu a strukturą danych: • w treści programu zakładamy konkretną postać struktur danych, • jeśli są to dane wejściowe lub wyjściowe, ich postać może się zmieniać w czasie, • zmiana struktury danych powoduje konieczność zmian w kodzie. • Uniezależnienie aplikacji od zmian struktury danych: • znaleźć reguły, według których następują zmiany struktury: • które reguły budowania struktury są niezmienne, • co się zmienia; • zakodować informacje zmienne w samej strukturze, • sparametryzować aplikację tymi informacjami. Poprawne modele zawartości. Zarządzanie zmianami struktury.

13. Zmiany struktury a aplikacje – przykład • Aplikacja: • edytor dokumentu XML przy pomocy formularza w przeglądarce, • każdemu elementowi dokumentu odpowiada pole formularza. • Co się może zmienić: • liczba i kolejność pól, • etykiety pól. • Jak uniezależnić aplikację od tych zmian? <!ELEMENT NIP (#PCDATA)><!ATTLIST NIP OPIS CDATA #FIXED "Numer Identyfikacji Podatkowej "> Poprawne modele zawartości. Zarządzanie zmianami struktury.

14. XML Namespaces • Problem: • ta sama nazwa oznacza dwa różne byty w różnych dokumentach, • dokumenty te są powiązane (np. wspólnie przetwarzane, jeden zanurzony w drugim, itp.) • Rozwiązanie: • przestrzeń nazw – grupa nazw oddzielona (składniowo i semantycznie) od innych nazw. • Status: rekomendacja W3C z 14 stycznia 1999 r. • Wątpliwości: • jak uniknąć (nieświadomego) korzystania z tych samych przestrzeni nazw do różnych celów, • jak definiować przestrzenie nazw. Poprawne modele zawartości. Zarządzanie zmianami struktury.

15. Deklarowanie i wykorzystanie przestrzeni nazw <xsl:stylesheet xmlns:xsl="http://www.w3.org/XSLT/Transform/1.0" xmlns:szz="http://SzymonZiolo.waw.pl"> <xsl:template match=”wzorzec”> <szz:template><xsl:apply-templates/></szz:template> </xsl:template></xsl:stylesheet> Poprawne modele zawartości. Zarządzanie zmianami struktury.

16. Widoczność przestrzeni nazw <?xml version="1.0"?><!-- initially, the default namespace is "books" --><book xmlns='http://library.gov/books'      xmlns:isbn='urn:ISBN:0-395-36341-6'>  <title>Cheaper by the Dozen</title>  <isbn:number>1568491379</isbn:number>  <notes>    <p xmlns='http://www.w3.org/1999/xhtml'>      This is a <i>funny</i> book!    </p>  </notes></book> Poprawne modele zawartości. Zarządzanie zmianami struktury.

17. Domyślna przestrzeń nazw • Domyślna przestrzeń nazw:<reln xmlns="http://www.w3.org/TR/REC-MathML/"> <eq/><cn>2</cn><cn>4</cn></reln> • Brak przestrzeni nazw:<przyklad> <reln xmlns="http://www.w3.org/TR/REC-MathML/"> <eq/><cn>2</cn><cn>4</cn> <notatka xmlns="">Czy to jest poprawne?</notatka> </reln></przyklad> Poprawne modele zawartości. Zarządzanie zmianami struktury.

18. Przestrzenie nazw atrybutów • Atrybut bez prefiksu nie jest w żadnej przestrzeni nazw (w szczególności nie jest w domyślnej)! <book xmlns:xlink="http://www.w3.org/XML/XLink/0.9"> <chapter number="1" xlink:type="simple" xlink:href="..."> <title>Introduction</title> </chapter></book> • element chapter jest w domyślnej przestrzeni nazw, • atrybut number nie ma przypisanej przestrzeni nazw – jest lokalny względem swojego elementu, • atrybut type jest w przestrzeni nazw XLink. Poprawne modele zawartości. Zarządzanie zmianami struktury.

19. Ograniczenia • Zabronione: • użycie niezadeklarowanego prefiksu przestrzeni nazw, • dwa atrybuty o tej samej nazwie i różnych prefiksach wskazujących na tą samą przestrzeń nazw:<x xmlns:n1="http://www.w3.org"    xmlns:n2="http://www.w3.org" >  <bad a="1"     a="2" />  <bad n1:a="1"  n2:a="2" /></x> • Ale to jest legalne: <x xmlns:n1="http://www.w3.org"    xmlns="http://www.w3.org" >  <good a="1"  b="2" />  <good a="1"  n1:a="2" /></x> Poprawne modele zawartości. Zarządzanie zmianami struktury.

20. Przestrzenie nazw a DTD • Dwa różne światy: • przestrzenie nazw sprawdzają się w dokumentach bez definicji struktury, • definiując DTD powinniśmy się obejść bez przestrzeni nazw. • Jeśli koniecznie chcemy używać ich razem: • prefiks przestrzeni nazw traktowany jako część nazwy, • brak semantyki przestrzeni nazw (a więc i wspomnianych ograniczeń). <!ELEMENT szz:p (#PCDATA)><!ATTLIST szz:p xmlns:szz CDATA #FIXED "http://SzymonZiolo.waw.pl/paragraf"><!ELEMENT pesel:p (imie, nazwisko, data-ur, stan-cyw)><!ATTLIST pesel:p xmlns:pesel CDATA #FIXED "http://pesel.gov.pl/person"> Poprawne modele zawartości. Zarządzanie zmianami struktury.

21. Przestrzenie nazw a XML Schema • Wsparcie dla przestrzeni nazw w XML Schema: • deklarowanie schematu w konkretnej przestrzeni nazw (targetNamespace), • importowanie przestrzeni nazw do schematu (import), • schematy rozszerzalne:<xsd:any namespace="URI-przestrzeni-nazw | ##any | ##local | ##targetNamespace | ##other" processContents="lax | skip | strict"/> Poprawne modele zawartości. Zarządzanie zmianami struktury.

22. Przestrzenie nazw a aplikacje niezależne od struktury • Przykład: XLink: • linki w elementach o dowolnych nazwach, • typ linku i jego parametry przekazywane przez specjalne atrybuty. <osoba xmlns:xlink="http://www.w3.org/1999/xlink"><nazwisko>Kopernik, Mikołaj</nazwisko><biogram>Wybitny polski astronom, urodzony w <geogr xlink:type="simple" xlink:href="Torun.xml">Toruniu</geogr>.</biogram></osoba> Poprawne modele zawartości. Zarządzanie zmianami struktury.

23. Przestrzenie nazw a aplikacje niezależne od struktury • Przykład: • aplikacja weryfikująca numery PESEL i daty urodzenia w dokumencie XML, • nie powinna zależeć od struktury dokumentu wejściowego, • jak „przekazać” aplikacji, co ma zweryfikować? • Rozwiązanie: <podanie xmlns:pv="http://PeselValidator.pl"> <nadawca nr-ewid="60101012345" pv:PESEL="nr-ewid"> <nazwisko>Zenon Niemrawy</nazwisko> <urodzony pv:data-ur="#CONTENT">1960-10-10 </urodzony> </nadawca> ...</podanie> Poprawne modele zawartości. Zarządzanie zmianami struktury.

24. Case studyXML jako format dokumentów ubezpieczeniowych ZUS

25. Tło projektu • Formularze ubezpieczeniowe: • 22 typy formularzy, • przesyłane okresowo przez płatników do ZUS, • dotychczas kodowane w pseudo-SGML-u. • Przyczyny zmiany formatu: • błędny projekt formatu SGML-owego, • rosnąca popularność XML-a, • nadchodząca zmiana rozporządzenia określającego strukturę formularzy. • Projekt badawczo-rozwojowy prowadzony przez empolis Polska w 2000 roku. Poprawne modele zawartości. Zarządzanie zmianami struktury.

26. Kolekcja Elektronicznych Dokumentów Ubezpieczeniowych Poprawne modele zawartości. Zarządzanie zmianami struktury.

27. Przykład: fragment formularza ZUS RCB Poprawne modele zawartości. Zarządzanie zmianami struktury.

28. Problemy • Wybór logicznego modelu struktury dokumentów: • model semantyczny, • model składniowy. • Modelowanie informacji pozwalających na walidację treści dokumentów. • Modelowanie informacji zwrotnych: • informacje o błędach w dokumentach, • informacje o korektach automatycznie wprowadzonych przez ZUS. • Oznaczenie pól wypełnianych przez ZUS. Poprawne modele zawartości. Zarządzanie zmianami struktury.

29. Semantyczny: Składniowy: DRZB DRZB dane-organizacyjne DRZB.01 termin-przys-dekl DRZB.01.01 ident-deklaracji DRZB.01.02 ... ... dane-ident-platnika DRZB.02 NIP DRZB.02.01 REGON DRZB.02.02 ... ... RCB RCB dane-organizacyjne RCB.01 ... ... dane-ident-platnika RCB.02 ... ... Logiczny model struktury dokumentów Poprawne modele zawartości. Zarządzanie zmianami struktury.

30. Logiczny model struktury dokumentów • Model semantyczny: • zwięzły i elegancki, • pozwala na modelowanie relacji wiele-do-wielu, • ale: nazwy szybko przestają być semantyczne. • Model składniowy: • łatwość automatyzacji przetwarzania: • operowanie nazwami elementów, • generowanie DTD oraz samych dokumentów, • możliwość wzbogacenia o informacje semantyczne. • Wybór: model składniowy. Poprawne modele zawartości. Zarządzanie zmianami struktury.

31. Modelowanie informacji dodatkowych • Informacje dodatkowe: • opisy pól, • informacje o sposobie walidacji pól, • informacje o polach wypełnianych przez ZUS. • Sposób kodowania: atrybuty #FIXED: • umieszczane w DTD wraz z wartościami, • wartości dostępne w instancji dokumentu, • nie ma możliwości zmiany wartości atrybutu w instancji dokumentu. Poprawne modele zawartości. Zarządzanie zmianami struktury.

32. Informacje dodatkowe – przykład <!ENTITY % a.wypelnia.zus "WYPELNIA.ZUS CDATA #FIXED 'TAK'"> <!ELEMENT DRSB.01.04 (#PCDATA)><!ATTLIST DRSB.01.04 OPIS CDATA #FIXED "Data nadania" TYP CDATA #FIXED "data" DLUGOSC CDATA #FIXED "8" %a.wypelnia.zus;> <!ELEMENT DRSB.02.04 (#PCDATA)><!ATTLIST DRSB.02.04 OPIS CDATA #FIXED "Rodzaj dokumentu" TYP CDATA #FIXED "kod" SLOWNIK CDATA #FIXED "rodzaj.dok"> Poprawne modele zawartości. Zarządzanie zmianami struktury.

33. Informacje zwrotne • Nie mogą być kodowane w atrybucie: • może być więcej niż jeden błąd lub korekta, dotycząca tego samego pola, • zawartości mogą zawierać podelementy, • niedozwolony model (#PCDATA, BLAD*, KOREKTA*) • Rozwiązanie: • opcjonalne elementy po elemencie, w którym wystąpił błąd. Poprawne modele zawartości. Zarządzanie zmianami struktury.

34. Informacje zwrotne – przykład <!ELEMENT BLAD EMPTY><!ATTLIST BLAD KOD CDATA #REQUIRED OPIS CDATA #IMPLIED><!ELEMENT KOREKTA ANY><!ATTLIST KOREKTA NR CDATA #REQUIRED TYP (OCR.1|OCR.2|OCR.3|SYSTEM) #REQUIRED> <!ENTITY % cm.inf.zwr "(BLAD*, KOREKTA*)"> <!ELEMENT DRSB ((DRSB.01, %cm.inf.zwr;)?, (DRSB.02, %cm.inf.zwr;)?, (DRSB.03, %cm.inf.zwr;)?, ... )> Poprawne modele zawartości. Zarządzanie zmianami struktury.

35. Przykład:reprezentacja w XML-u Poprawne modele zawartości. Zarządzanie zmianami struktury.

36. Gdzie szukać dalej • Namespaces in XML, W3C Recommendation: • www.w3.org/TR/1999/REC-xml-names • Zioło, Sz., Sztuka hodowli drzew, czyli modele zawartości dokumentów XML • Software 2.0, nr 6/2001, Wydawnictwo Software • www.empolis.pl  Materiały  Artykuły • Zioło, Sz., Jak pozostać niezależnym od DTD • Software 2.0, nr 6/2002, Wydawnictwo Software • Górski, C., Zioło, Sz., Wykorzystanie XML-a w zarządzaniu formularzami ubezpieczeniowymi ZUS • www.empolis.pl  Materiały  Artykuły Poprawne modele zawartości. Zarządzanie zmianami struktury.