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

Prezentacja na temat: "11 Poprawne modele zawartości. Zarządzanie zmianami struktury."— Zapis prezentacji:

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

2 22 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 33 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 44 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 55 Model niejednoznaczny Równoważny model poprawny:

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

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

8 88 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 99 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 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. #IMPLIED>

11 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 12 Zmiany struktury a aplikacje Problem: aplikacja wykorzystująca dokumenty XML zakłada określoną ich strukturę, struktura zmienia się w sposób niekompatybilny wstecz, trzeba dostosować aplikację. Rozwiązanie: opracujmy konwencję kodowania informacji, które mogą się zmieniać, sparametryzujmy naszą aplikację tymi informacjami.

13 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 14 Podobne techniki Kilka wersji DTD na raz: sekcje warunkowe + encje parametryczne wykład 3. Całkowite uniezależnienie aplikacji od struktury dokumentów: odwzorowanie jednej DTD na inną – formy architektoniczne, "znakowanie" elementów znaczących dla aplikacji – przestrzenie nazw.

15 15 Case study XML w zarządzaniu formularzami ubezpieczeniowymi ZUS

16 16 Czym jest KEDU – Wersja I? Kolekcja Elektronicznych Dokumentów Ubezpieczeniowych. Prosta aplikacja SGML. Modelowanie (SGML) do poziomu bloków danych. Stałopozycyjny zapis danych elementarnych – tak, jak na papierze.

17 17 Dlaczego opracowano następcę? Zmiana wymagań ZUS na informacje ubezpieczeniowe od płatników: Nowa edycja formularzy ubezpieczeniowych – tzw. seria B, Konieczność dostosowania systemu do obsługi nowych formularzy. Przy okazji: Usunięcie niedogodności ujawnionych podczas eksploatacji, Zmiana technologii na bardziej przyjazną.

18 18 Czym jest KEDU – Wersja II? Aplikacja XML wykorzystująca pulę najbardziej użytecznych właściwości standardu. Modelowanie do poziomu danych elementarnych. Wsparcie w DTD mechanizmów walidacji dziedziny i formatu danych. Mechanizmy wizualizacji wykorzystujące XSLT i przeglądarkę internetową.

19 19 KEDU wersja II

20 20 Jak to wygląda w praktyce

21 21 Logiczny model struktury dokumentów 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... Semantyczny:Składniowy:

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

23 23 Modelowanie informacji dodatkowych Informacje dodatkowe –parametry elementów struktury: opisy pól, informacje o sposobie weryfikacji zawartości 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.

24 24 Informacje dodatkowe – przykład

25 25 Informacje zwrotne – implementacja Problemy: może być więcej niż jeden błąd lub korekta, dotycząca tego samego pola, zawartości mogą zawierać podelementy. Rozwiązanie: opcjonalne elementy BLAD i KOREKTA po elemencie, w którym wystąpił błąd, niemożność umieszczenia wewnątrz elementów, których dotyczą (niedozwolony model (#PCDATA, BLAD*, KOREKTA*) ). Wartość pierwotna skorygowanego pola: zawartość elementu KOREKTA.

26 26 Jak to wygląda w praktyce? – reprezentacja w XML