Poprawne modele zawartoci Zarzdzanie zmianami struktury 2004 10

Poprawne modele zawartości. Zarządzanie zmianami struktury. 2004 -10 -28 Poprawne modele zawartości. Zarządzanie zmianami struktury.

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: – ? ? ? 2004 -10 -28 Poprawne modele zawartości. Zarządzanie zmianami struktury. 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> Równoważny model poprawny: <!ELEMENT hasło (pojęcie, znaczenie)> <!ELEMENT znaczenie (#PCDATA)> 2004 -10 -28 Poprawne modele zawartości. Zarządzanie zmianami struktury. 3

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: <!ELEMENT znaczenie (treść | definicja)> <!ELEMENT treść (#PCDATA)> 2004 -10 -28 Poprawne modele zawartości. Zarządzanie zmianami struktury. 4

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

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

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

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

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

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

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

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

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 W 3 C 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. 14

Deklarowanie i wykorzystanie przestrzeni nazw <xsl: stylesheet xmlns: xsl="http: //www. w 3. org/XSLT/Transform/1. 0" xmlns: szz="http: //Szymon. Ziolo. waw. pl"> <xsl: template match=”wzorzec”> <szz: template><xsl: apply-templates/></szz: template> </xsl: stylesheet> 2004 -10 -28 Poprawne modele zawartości. Zarządzanie zmianami struktury. 15

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. w 3. org/1999/xhtml'> This is a <i>funny</i> book! </p> </notes> </book> 2004 -10 -28 Poprawne modele zawartości. Zarządzanie zmianami struktury. 16

Domyślna przestrzeń nazw • Domyślna przestrzeń nazw: <reln xmlns="http: //www. w 3. org/TR/REC-Math. ML/"> <eq/><cn>2</cn><cn>4</cn> </reln> • Brak przestrzeni nazw: <przyklad> <reln xmlns="http: //www. w 3. org/TR/REC-Math. ML/"> <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. 17

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

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: <x xmlns: n 1="http: //www. w 3. org" xmlns: n 2="http: //www. w 3. org" > <bad a="1" a="2" /> <bad n 1: a="1" n 2: a="2" /> </x> • Ale to jest legalne: <x xmlns: n 1="http: //www. w 3. org" xmlns="http: //www. w 3. org" > <good a="1" b="2" /> <good a="1" n 1: a="2" /> </x> 2004 -10 -28 Poprawne modele zawartości. Zarządzanie zmianami struktury. 19

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: //Szymon. Ziolo. 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. 20

Przestrzenie nazw a XML Schema • Wsparcie dla przestrzeni nazw w XML Schema: – deklarowanie schematu w konkretnej przestrzeni nazw (target. Namespace), – importowanie przestrzeni nazw do schematu (import), – schematy rozszerzalne: <xsd: any namespace="URI-przestrzeni-nazw | ##any | ##local | ##target. Namespace | ##other" process. Contents="lax | skip | strict"/> 2004 -10 -28 Poprawne modele zawartości. Zarządzanie zmianami struktury. 21

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

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: //Pesel. Validator. 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. 23

Case study XML jako format dokumentów ubezpieczeniowych ZUS 2004 -10 -28 Poprawne modele zawartości. Zarządzanie zmianami struktury.

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

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

Przykład: fragment formularza ZUS RCB 2004 -10 -28 Poprawne modele zawartości. Zarządzanie zmianami struktury. 27

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

Logiczny model struktury dokumentów Semantyczny: DRZB dane-organizacyjne termin-przys-dekl ident-deklaracji. . . dane-ident-platnika NIP REGON. . . Składniowy: DRZB. 01. 02. . . DRZB. 02. 01 DRZB. 02. . . RCB dane-organizacyjne. . . RCB. 01. . . dane-ident-platnika. . . RCB. 02. . . 2004 -10 -28 Poprawne modele zawartości. Zarządzanie zmianami struktury. 29

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

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

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

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

Informacje zwrotne – przykład <!ELEMENT BLAD <!ATTLIST BLAD 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*)"> <!ELEMENT DRSB ((DRSB. 01, %cm. inf. zwr; )? , (DRSB. 02, %cm. inf. zwr; )? , (DRSB. 03, %cm. inf. zwr; )? , . . . )> 2004 -10 -28 Poprawne modele zawartości. Zarządzanie zmianami struktury. 34

Przykład: reprezentacja w XML-u 2004 -10 -28 Poprawne modele zawartości. Zarządzanie zmianami struktury. 35

Gdzie szukać dalej • Namespaces in XML, W 3 C Recommendation: ü www. w 3. org/TR/1999/REC-xml-names • Zioło, 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 ü www. empolis. pl Materiały Artykuły 2004 -10 -28 Poprawne modele zawartości. Zarządzanie zmianami struktury. 36