XML a białe znaki. Poprawne modele zawartości. Zarządzanie zmianami struktury. Model błędnej zawartości (1) Model błędnej zawartości (2)

Transkrypt

1 XML a białe znaki 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:??? 2 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> <!ELEMENT hasło (pojęcie, znaczenie)> <!ELEMENT znaczenie (#PCDATA)> 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> <!ELEMENT znaczenie (treść definicja)> <!ELEMENT treść (#PCDATA)> 3 4 Model niejednoznaczny <!ELEMENT hasło (pojęcie, znaczenie?, etymologia?, znaczenie)> <!ELEMENT hasło (pojęcie, ((znaczenie, (etymologia?, znaczenie)?) (etymologia, znaczenie)))> Elementy w dowolnej kolejności (1) Konstrukcja SGML-owa: <!ELEMENT wielojęz - - (pol & ang)> <!ELEMENT wielojęz ((pol, ang) (ang, pol))> 5 6

2 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. 7 8 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)*> 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> 9 10 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

3 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 <xsl:stylesheet xmlns:xsl=" xmlns:szz=" <xsl:template match= wzorzec > <szz:template><xsl:apply-templates/></szz:template> </xsl:template> </xsl:stylesheet> Widoczność przestrzeni nazw <?xml version="1.0"?> <!-- initially, the default namespace is "books" --> <book xmlns=' xmlns:isbn='urn:isbn: '> <title>cheaper by the Dozen</title> <isbn:number> </isbn:number> <notes> <p xmlns=' This is a <i>funny</i> book! </p> </notes> </book> Domyślna przestrzeń nazw Przestrzenie nazw atrybutów Domyślna przestrzeń nazw: <reln xmlns=" <eq/><cn>2</cn><cn>4</cn> </reln> Brak przestrzeni nazw: <przyklad> <reln xmlns=" <eq/><cn>2</cn><cn>4</cn> <notatka xmlns="">czy to jest poprawne?</notatka> </reln> </przyklad> Atrybut bez prefiksu nie jest w żadnej przestrzeni nazw (w szczególności nie jest w domyślnej)! <book xmlns:xlink=" <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

4 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=" xmlns:n2=" > <bad a="1" a="2" /> <bad n1:a="1" n2:a="2" /> </x> Ale to jest legalne: <x xmlns:n1=" xmlns=" > <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 " <!ELEMENT pesel:p (imie, nazwisko, data-ur, stan-cyw)> <!ATTLIST pesel:p xmlns:pesel CDATA #FIXED " 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"/> 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=" <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=" <nadawca nr-ewid=" " pv:pesel="nr-ewid"> <nazwisko>zenon Niemrawy</nazwisko> <urodzony pv:data-ur="#content"> </urodzony> </nadawca> </podanie> Case study XML jako format dokumentów ubezpieczeniowych ZUS 23

5 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. Kolekcja Elektronicznych Dokumentów Ubezpieczeniowych 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 DRZB DRZB.02 DRZB DRZB 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

6 Modelowanie informacji dodatkowych Informacje dodatkowe przykład Informacje dodatkowe: <!ENTITY % a.wypelnia.zus "WYPELNIA.ZUS CDATA #FIXED 'TAK'"> <!ELEMENT DRSB (#PCDATA)> <!ATTLIST DRSB OPIS CDATA #FIXED "Data nadania" TYP CDATA #FIXED "data" DLUGOSC CDATA #FIXED "8" %a.wypelnia.zus;> <!ELEMENT DRSB (#PCDATA)> <!ATTLIST DRSB OPIS CDATA #FIXED "Rodzaj dokumentu" TYP CDATA #FIXED "kod" SLOWNIK CDATA #FIXED "rodzaj.dok"> 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. 31 Informacje zwrotne Informacje zwrotne przykład Nie mogą być kodowane w atrybucie: <!ELEMENT BLAD <!ATTLIST BLAD 32 EMPTY> 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*)"> 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 DRSB ((DRSB.01, %cm.inf.zwr;)?, (DRSB.02, %cm.inf.zwr;)?, (DRSB.03, %cm.inf.zwr;)?, )> 33 Przykład: reprezentacja w XML-u 34 Gdzie szukać dalej Namespaces in XML, W3C Recommendation: Þ Zioło, Sz., Sztuka hodowli drzew, czyli modele zawartości dokumentów XML Software 2.0, nr 6/2001, Wydawnictwo Software Þ t Materiały t 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 Þ t Materiały t Artykuły