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

XML a białe znaki W modelu elementowym: W modelu tekstowym/mieszanym: ignorowane, służą jedynie zwiększeniu czytelności. W modelu tekstowym/mieszanym: stanowią część zawartości tekstowej. Na granicy modeli: ??? Notatki do tej sesji są fragmentami artykułu: S. Zioło, Sztuka hodowli drzew, czyli modele zawartości dokumentów XML, Software 2.0, nr 6'2001. 2004-10-28 Poprawne modele zawartości. Zarządzanie zmianami struktury.

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)> Deklaracja przedstawiona na górze sama w sobie nie jest niepoprawna, lecz sprawia kłopoty w przypadku przetwarzania dokumentów, w których element oddzielony jest od części znakowej białym znakiem. Parser nie jest wówczas w stanie stwierdzić, czy biały znak występujący na styku dwóch modeli (w naszym przykładzie jest nim znak końca wiersza) należy zignorować, gdyż służy jedynie zwiększeniu czytelności, czy też może potraktować jako część zawartości znakowej. Tego rodzaju modele nazywamy modelami błędnej zawartości (bad content models). Powinniśmy ich oczywiście unikać konstruując DTD. Na szczęście modele takie można łatwo przekształcać w modele poprawne, nie zmniejszając ich siły wyrazu. 2004-10-28 Poprawne modele zawartości. Zarządzanie zmianami struktury.

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: Sytuacja jest podobna do przedstawionej na poprzednim slajdzie, lecz tym razem objawia się w momencie wyboru między jedną z dwóch alternatyw. <!ELEMENT znaczenie (treść | definicja)> <!ELEMENT treść (#PCDATA)> 2004-10-28 Poprawne modele zawartości. Zarządzanie zmianami struktury.

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)))> Ograniczenie parserów XML, polegające na niemożności „podglądania” nie przeanalizowanego jeszcze tekstu, występuje nie tylko – jak w poprzednich przykładach – na poziomie pojedynczych znaków, lecz także na poziomie całych elementów. Powoduje to, że niektóre modele zawartości elementowej także są niepoprawne. Podczas przetwarzania zawartości zgodnej z tą deklaracją, parser bezpośrednio po elemencie pojęcie może napotkać element znaczenie. Nie jest wtedy jednak w stanie stwierdzić, czy jest to pierwsze, opcjonalne wystąpienie tego elementu, czy też ostatni podelement elementu hasło. Wiadomo o tym dopiero po zamknięciu pierwszego elementu znaczenie. Taki model nazywamy modelem niejednoznacznym (ambiguous content model). 2004-10-28 Poprawne modele zawartości. Zarządzanie zmianami struktury.

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))> Niekiedy, w pewnych specyficznych zastosowaniach, pojawia się wymaganie, aby podelementy deklarowanego elementu mogły pojawić się w dowolnej kolejności, lecz aby każdy z nich wystąpił dokładnie jeden raz. Model taki definiuje się bardzo łatwo w SGML-owych DTD, których składnia oferuje operator &. Uproszczenia wprowadzone w składni XML-a w stosunku do SGML-a sprawiły jednak, że ten elegancki operator jest w XML-owych DTD niedostępny. Co więcej, równoważny mu, podobnie zwięzły i elegancki model, nie istnieje. Jedynym wyjściem jest więc użycie złożonego modelu opartego na alternatywie. 2004-10-28 Poprawne modele zawartości. Zarządzanie zmianami struktury.

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))))> Jak widzimy, złożoność modelu XML-owego rośnie wykładniczo w stosunku do ilości elementów. Można się jedynie pocieszać, że tego typu model występuje w realnych zastosowaniach stosunkowo rzadko. 2004-10-28 Poprawne modele zawartości. Zarządzanie zmianami struktury.

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. 2004-10-28 Poprawne modele zawartości. Zarządzanie zmianami struktury.

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)*> We wszystkich podanych zmianach, zawartość dopuszczalna do tej pory (przed zmianą) jest zgodna z modelem także po zmianie. Dodatkowo, zmieniony model pozwala na zakodowanie struktur, które do tej pory były niedopuszczalne. Dlatego zmiana w drugą stronę nie jest kompatybilna wstecz. 2004-10-28 Poprawne modele zawartości. Zarządzanie zmianami struktury.

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> 2004-10-28 Poprawne modele zawartości. Zarządzanie zmianami struktury.

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. 2004-10-28 Poprawne modele zawartości. Zarządzanie zmianami struktury.

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. 2004-10-28 Poprawne modele zawartości. Zarządzanie zmianami struktury.

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 "> 2004-10-28 Poprawne modele zawartości. Zarządzanie zmianami struktury.

XML Namespaces Problem: Rozwiązanie: 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. 2004-10-28 Poprawne modele zawartości. Zarządzanie zmianami struktury.

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> 2004-10-28 Poprawne modele zawartości. Zarządzanie zmianami struktury.

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> 2004-10-28 Poprawne modele zawartości. Zarządzanie zmianami struktury.

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> 2004-10-28 Poprawne modele zawartości. Zarządzanie zmianami struktury.

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. 2004-10-28 Poprawne modele zawartości. Zarządzanie zmianami struktury.

Ograniczenia Zabronione: Ale to jest legalne: 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> 2004-10-28 Poprawne modele zawartości. Zarządzanie zmianami struktury.

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"> 2004-10-28 Poprawne modele zawartości. Zarządzanie zmianami struktury.

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"/> 2004-10-28 Poprawne modele zawartości. Zarządzanie zmianami struktury.

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> 2004-10-28 Poprawne modele zawartości. Zarządzanie zmianami struktury.

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> 2004-10-28 Poprawne modele zawartości. Zarządzanie zmianami struktury.

Case study XML jako format dokumentów ubezpieczeniowych ZUS

Tło projektu Formularze ubezpieczeniowe: Przyczyny zmiany formatu: 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. Wszystkie formularze powstają najpierw w wersji papierowej i dopiero na jej podstawie projektuje się wersje elektroniczne, dbając, aby były one zgodne co do struktury z wersjami papierowymi. Dotychczas formularze są kodowane w formacie zaprojektowanym przez Prokom. Był to SGML, obwarowany wieloma zastrzeżeniami, często niezgodnymi z ideą SGML-a. Wszystkie wartości pól trzeba np. uzupełniać spacjami do ich pełnej długości – takiej jak na formularzu papierowym. Elementy posiadają ponadto wewnętrzną strukturę, nie modelowaną w SGML-u. Dlatego tak na prawdę jest to format stałopozycyjny, dla którego nie jest potrzebne oznakowanie SGML-owe. Na marginesie, nikt nie używa zaprojektowanego przez Prokom DTD w parserze SGML-owym, ponieważ DTD to zawiera błąd. Wygląda więc na to, że wszystkie aplikacje generujące dane w tym formacie używają własnych mechanizmów generowania, a nie standardowych parserów! 2004-10-28 Poprawne modele zawartości. Zarządzanie zmianami struktury.

Kolekcja Elektronicznych Dokumentów Ubezpieczeniowych 2004-10-28 Poprawne modele zawartości. Zarządzanie zmianami struktury.

Przykład: fragment formularza ZUS RCB Formularze mają ściśle określoną strukturę: składają się z bloków, bloki z podbloków lub bezpośrednio z pól, pola zawierają właściwe wartości, lub niekiedy składają się z sekcji. Niezależnie od tej budowy logicznej, grupy pól w ramach bloków są często wizualizowane w postaci tabelek lub inaczej grupowane. 2004-10-28 Poprawne modele zawartości. Zarządzanie zmianami struktury.

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. Podstawowym problemem do rozwiązania był sposób modelowania logicznej struktury dokumentów ubezpieczeniowych (szczegóły dalej). Wartości umieszczane w polach formularzy mają określone typy i maksymalne długości (odpowiadające długości pól w formularzach papierowych). Często także dla zawartości pól (np. dla dat) określa się sposób ich formatowania. Mechanizm DTD oraz parsery z niego korzystające nie pozwalają na modelowanie takich ograniczeń na wartości pól. Dlatego trzeba było znaleźć inny sposób na zapisanie tych informacji w DTD, pozwalający na ich wykorzystanie przez aplikacje przetwarzające. W tym miejscu najbardziej brakowało nam standardu XML-Schema i narzędzi go wspierających. W przypadku błędów w formularzach, są one zwracane płatnikom wraz z informacjami o błędach oraz o wprowadzonych korektach (niekiedy ZUS może sam skorygować wartość błędnego pola). Dlatego projektowane DTD musiało umożliwiać kodowanie takich informacji. Wreszcie niektóre pola formularzy są wypełniane dopiero przez ZUS. Można by więc ich nie modelować w wersji DTD przeznaczonej dla płatników, gdyby nie fakt, że formularze są zwracane płatnikom w razie wykrycia w nich błędów. Dlatego pola takie trzeba było umieścić w modelu, zaznaczając (w sposób umożliwiający wykorzystanie przez aplikacje), że są one wypełniane przez ZUS. 2004-10-28 Poprawne modele zawartości. Zarządzanie zmianami struktury.

Logiczny model struktury dokumentów Semantyczny: Składniowy: DRZB dane-organizacyjne termin-przys-dekl ident-deklaracji dane-ident-platnika NIP REGON ... RCB DRZB DRZB.01 DRZB.01.01 DRZB.01.02 DRZB.02 DRZB.02.01 DRZB.02.02 ... RCB RCB.01 RCB.02 Model semantyczny polega na wyodrębnieniu z zestawu formularzy bloków i pól o takim samym znaczeniu i strukturze oraz zamodelowaniu ich jako pojedynczych elementów. Nazwy elementów opisują wówczas ich znaczenie, a nie pozycje w formularzach. Model składniowy polega na zdefiniowaniu osobnego elementu XML dla każdego pola i każdego bloku istniejących formularzy. Powtarzające się pola i bloki o tym samym znaczeniu są w tym modelu definiowane jako osobne elementy. Model ten pozwala na nadanie elementom nazw odpowiadających numeracji bloków, podbloków, pól i sekcji. 2004-10-28 Poprawne modele zawartości. Zarządzanie zmianami struktury.

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. Wydaje się, że model semantyczny jest lepszy, bo oferuje się w nim elementami, których nazwy opisują znaczenie zawartości – zgodnie z ideologią XML-a. Ale w formularzach jest wiele pól o „barokowych” opisach, np. Liczba dni kalendarzowych, za które należy opłacić składki za dany miesiąc (wpisać tylko dla osób, które mają ustaloną minimalną podstawę, gdy liczba ta jest mniejsza niż liczba dni w danym miesiącu). Takie nazwy trzeba by skracać, co doprowadziłoby do bałaganu przy tworzeniu skrótów. Skróty przestały by być semantyczne i nie byłoby gwarancji, że niechcący nie skrócimy dwóch różnych nazw do tego samego skrótu. Wybraliśmy model składniowy, mimo jego rozwlekłości i brzydoty. Można go bowiem wzbogacić o informacje semantyczne np. w postaci atrybutów OPIS zawierających etykiety pól z formularzy papierowych. Po takim wyborze jedynym wyjściem było wygenerowanie DTD z bazy danych zawierającej definicje bloków, podbloków, pól i sekcji. Tak utworzone DTD ma ok. 400 KB! 2004-10-28 Poprawne modele zawartości. Zarządzanie zmianami struktury.

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. Zgodnie z opisanymi wcześniej problemami, informacje zwrotne powinny być zakodowane w DTD w sposób umożliwiający ich wykorzystanie przez aplikacje generujące lub przetwarzające dokumenty. Takim sposobem mogą być atrybuty #FIXED, których ustalone wartości (tylko do odczytu) podaje się w DTD. Jedynie informacje zwrotne są kodowane w inny sposób. 2004-10-28 Poprawne modele zawartości. Zarządzanie zmianami struktury.

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"> Atrybut OPIS zawiera etykietę pola taką, jak na formularzu papierowym. Informacje semantyczne są kodowane przy pomocy atrybutów TYP, DLUGOSC oraz FORMAT. TYP zawiera nazwę typu (lista typów jest ustalona). FORMAT zawiera wyrażenie regularne opisujące dopuszczalny format zawartości pola. Jeżeli wartość pola należy do ustalonego zbioru wartości (kodów), wówczas przy pomocy atrybutu SLOWNIK odwołujemy się do słownika (umieszczonego w osobnym pliku) zawierającego zbiór dopuszczalnych wartości. Informacja o tym, że pole jest wypełniane przez ZUS jest podawana przy pomocy atrybutu WYPELNIA.ZUS, którego – dla ułatwienia zarządzania – używa się przy pomocy encji parametrycznej a.wypelnia.zus. 2004-10-28 Poprawne modele zawartości. Zarządzanie zmianami struktury.

Informacje zwrotne Nie mogą być kodowane w atrybucie: Rozwiązanie: 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. 2004-10-28 Poprawne modele zawartości. Zarządzanie zmianami struktury.

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;)?, ... )> Definiujemy wspólne dla wszystkich bloków i pól elementy reprezentujące błędy i korekty. Zawartością elementu KOREKTA jest skorygowana wartość (słowo kluczowe ANY pozwala na dowolną zawartość). Elementów tych używamy odwołując się do encji parametrycznej cm.inf.zwr. Ponieważ w XML-u zawartością elementu nie może być „#PCDATA, %cm.inf.zwr;”, trzeba było umieścić elementy dla błędu i korekty obok elementu, którego błąd lub korekta dotyczy. 2004-10-28 Poprawne modele zawartości. Zarządzanie zmianami struktury.

Przykład: reprezentacja w XML-u Slajd przedstawia częściowo „zwiniętą” wersję reprezentacji elektronicznej formularza z poprzedniego slajdu, tak jak wyświetla go Internet Exploerer przy pomocy domyślnego arkusza stylów. Szczegóły: główny element – KEDU2, element RCB – odpowiada całemu dokumentowi ZUS RCB, bloki I, II i V są „zwinięte”, blok III jest rozwinięty w całości, pole RCB.III.B.08 składa się z dwóch segmentów, do pola RCB.III.B.12 została przypięta korekta systemowa, do całego bloku RCB.III przypięto błędy. 2004-10-28 Poprawne modele zawartości. Zarządzanie zmianami struktury.

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 2004-10-28 Poprawne modele zawartości. Zarządzanie zmianami struktury.