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

1. Poprawne modele zawartości. Zarządzanie zmianami struktury. 30 października 2003

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: • ???

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)>

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)>

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)))>

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))>

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))))>

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.

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 (imie, nazwisko, adres*)> • Dodanie elementu do alternatywy: • <!ELEMENT podróż (samochód | pociąg | samolot | rakieta)*>

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>

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.

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.

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"

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.

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>

16. Widoczność przestrzeni nazw • <?xml version="1.0"?><!-- initially, the default namespace is "books" --><book xmlns='urn:loc.gov:books'      xmlns:isbn='urn:ISBN:0-395-36341-6'>  <title>Cheaper by the Dozen</title>  <isbn:number>1568491379</isbn:number>  <notes>    <p xmlns='urn:w3-org-ns:HTML'>      This is a <i>funny</i> book!    </p>  </notes></book>

17. Domyślna i lokalna przestrzeń nazw • Domyślna przestrzeń nazw:<reln xmlns="http://www.w3.org/TR/REC-MathML/"> <eq/><cn>2</cn><cn>4</cn></reln> • Lokalna przestrzeń 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>

18. Przestrzenie nazw atrybutów • <book xmlns:xlink="http://www.w3.org/XML/XLink/0.9"> <chapter number="1" xlink:type="simple" xlink:href="..."> <title>Introduction</title> </chapter></book> • Atrybut bez prefiksu jest formalnie w innej przestrzeni nazw niż element! • element chapter jest w domyślnej przestrzeni nazw, • atrybut number jest w lokalnej przestrzeni nazw elementu chapter, • atrybut type jest w przestrzeni nazw XLink.

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>

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">

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"/>

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>

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</data-ur> </nadawca> ...</podanie>

24. Case study:XML 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.

26. Kolekcja Elektronicznych Dokumentów Ubezpieczeniowych

27. Przykład: fragment formularza ZUS RCB

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.

29. Logiczny model struktury dokumentów 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 ... ...

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.

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.

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">

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.

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;)?, ... )>

35. Przykład:reprezentacja w XML-u

36. Gdzie szukać dalej Namespaces in XML, W3C Recommendation: • www.w3.org/TR/1999/REC-xml-names Szymon Zioło, Sztuka hodowli drzew, czyli modele zawartości dokumentów XML • Software 2.0, nr 6/2001, Wydawnictwo Software • www.empolis.pl  Osiągnięcia  Archiwum publikacji Szymon Zioło, Jak pozostać niezależnym od DTD • Software 2.0, nr 6/2002, Wydawnictwo Software • Cezary Górski, Szymon Zioło, Wykorzystanie XML-a w zarządzaniu formularzami ubezpieczeniowymi ZUS • www.empolis.pl  Osiągnięcia  Publikacje