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

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

Model błędnej zawartości (1) zombie w religiach afrykańskich: osoba zmarła, która może ożyć dzięki magii Równoważny model poprawny:

Model błędnej zawartości (2) półpłaszczyzna domknięta jedna z dwu części płaszczyzny, na które prosta L dzieli tę płaszczyznę, wraz z tą prostą Równoważny model poprawny:

Model niejednoznaczny Równoważny model poprawny:

Elementy w dowolnej kolejności (1) Konstrukcja SGML-owa: Równoważny model poprawny:

Elementy w dowolnej kolejności (2) Konstrukcja SGML-owa: Równoważny model poprawny:

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.

Dozwolone zmiany w DTD (1) Dodanie elementu opcjonalnego Zmiana krotności elementu: z wymaganego na opcjonalny, z jednokrotnego na powtarzalny. Dodanie elementu do alternatywy:

Dozwolone zmiany w DTD (2) Dodanie atrybutu: opcjonalnego, z wartością domyślną, #FIXED 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.

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.

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.

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? <!ATTLIST NIP OPIS CDATA #FIXED "Numer Identyfikacji Podatkowej"

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.

Deklarowanie i wykorzystanie przestrzeni nazw

Widoczność przestrzeni nazw Cheaper by the Dozen This is a funny book!

Domyślna i lokalna przestrzeń nazw Domyślna przestrzeń nazw: 2 4 Lokalna przestrzeń nazw: 2 4 Czy to jest poprawne?

Przestrzenie nazw atrybutów Introduction 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.

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: Ale to jest legalne:

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

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:

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. Kopernik, Mikołaj Wybitny polski astronom, urodzony w Toruniu.

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: Zenon Niemrawy

Case study: XML jako format dokumentów ubezpieczeniowych ZUS

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.

Kolekcja Elektronicznych Dokumentów Ubezpieczeniowych

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 Semantyczny:Składniowy: DRZB dane-organizacyjne termin-przys-dekl ident-deklaracji dane-ident-platnika NIP REGON... RCB dane-organizacyjne dane-ident-platnika... DRZB DRZB.01 DRZB DRZB DRZB.02 DRZB DRZB RCB RCB.01 RCB.02...

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.

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.

Informacje dodatkowe – przykład

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.

Informacje zwrotne – przykład

Przykład: reprezentacja w XML-u

Gdzie szukać dalej Namespaces in XML, W3C Recommendation: Szymon Zioło, Sztuka hodowli drzew, czyli modele zawartości dokumentów XML Software 2.0, nr 6/2001, Wydawnictwo Software 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 Osiągnięcia Publikacje