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

Prezentacja na temat: "Poprawne modele zawartości. Zarządzanie zmianami struktury. 30 października 2003."— Zapis prezentacji:

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) zombie w religiach afrykańskich: osoba zmarła, która może ożyć dzięki magii Równoważny model poprawny:

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

5 Model niejednoznaczny Równoważny model poprawny:

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

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

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 Zmiana krotności elementu: z wymaganego na opcjonalny, z jednokrotnego na powtarzalny. Dodanie elementu do alternatywy:

10 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.

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

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

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

18 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.

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

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

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:

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

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: Zenon Niemrawy 1960-10-10...

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 dane-organizacyjne termin-przys-dekl ident-deklaracji dane-ident-platnika NIP REGON... RCB dane-organizacyjne dane-ident-platnika... DRZB DRZB.01 DRZB.01.01 DRZB.01.02 DRZB.02 DRZB.02.01 DRZB.02.02... RCB RCB.01 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

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

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