XML a białe znaki 30 października 2003 Poprawne modele zawartości. Zarządzanie zmianami struktury. W modelu elementowym: ignorowane, służą jedynie zwiększeniu czytelności. W modelu tekstowym/mieszanym: stanowią część zawartości tekstowej. Na granicy modeli:??? Model błędnej zawartości (1) Model błędnej zawartości (2) <!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> <!ELEMENT hasło (pojęcie, znaczenie)> <!ELEMENT znaczenie (#PCDATA)> <!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> <!ELEMENT znaczenie (treść definicja)> <!ELEMENT treść (#PCDATA)> Model niejednoznaczny Elementy w dowolnej kolejności (1) <!ELEMENT hasło (pojęcie, znaczenie?, etymologia?, znaczenie)> <!ELEMENT hasło (pojęcie, ((znaczenie, (etymologia?, znaczenie)?) (etymologia, znaczenie)))> Konstrukcja SGML-owa: <!ELEMENT wielojęz - - (pol & ang)> <!ELEMENT wielojęz ((pol, ang) (ang, pol))> 1
Elementy w dowolnej kolejności (2) Zarządzanie zmianami w DTD Konstrukcja SGML-owa: <!ELEMENT wielojęz - - (pol & ang & niem)> <!ELEMENT wielojęz ((pol, ((ang, niem) (niem, ang))) (ang, ((pol, niem) (niem, pol))) (niem, ((pol, ang) (ang, pol))))> 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? nowy model musi być bardziej ogólny od dotychczasowego. Dozwolone zmiany w DTD (1) Dozwolone zmiany w DTD (2) 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)*> 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> Jak zarządzać zmianami Zmiany struktury a aplikacje 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. 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. 2
Zmiany struktury a aplikacje przykład XML Namespaces 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" 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.) 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. Deklarowanie i wykorzystanie przestrzeni nazw Widoczność 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> <?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> Domyślna i lokalna przestrzeń nazw Przestrzenie nazw atrybutów 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> <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. 3
Ograniczenia Przestrzenie nazw a DTD 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> 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"> Przestrzenie nazw a XML Schema Przestrzenie nazw a aplikacje niezależne od struktury 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"/> 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> 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ć? <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> Case study: XML jako format dokumentów ubezpieczeniowych ZUS 4
Tło projektu Kolekcja Elektronicznych Dokumentów Ubezpieczeniowych 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. ZUS ZFB I. Dane organizacyjne 01. Identyfikator raportu 1 Nr raportu 2 Okres rozliczeniowy 02. Kod terytorialny KEDU Kolekcja Elektronicznych Dokumentów Ubezpieczeniowych II. Dane identyfikacyjne płatnika składek 01. NIP 02. REGON 03. PESEL ZUS RCB III. Dane dotyczące osoby ubezpieczonej A.01. Nazwisko A.02. Imię pierwsze B.01. Kod tytułu ubezpieczenia V. Oświadczenie płatnika składek 01. Data wypełnienia Przykład: fragment formularza ZUS RCB 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. Logiczny model struktury dokumentów Logiczny model struktury dokumentów Semantyczny: DRZB dane-organizacyjne termin-przys-dekl ident-deklaracji dane-ident-platnika NIP REGON RCB dane-organizacyjne dane-ident-platnika Składniowy: DRZB DRZB.01 DRZB.01.01 DRZB.01.02 DRZB.02 DRZB.02.01 DRZB.02.02 RCB RCB.01 RCB.02 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. 5
Modelowanie informacji dodatkowych Informacje dodatkowe przykład 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. <!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"> Informacje zwrotne Informacje zwrotne przykład 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*)) opcjonalne elementy po elemencie, w którym wystąpił błąd. <!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;)?, )> Przykład: reprezentacja w XML-u 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 6