poprawne modele zawartości. zarządzanie zmianami struktury

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

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


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


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>


<!ELEMENT znaczenie (treść | definicja)>

<!ELEMENT treść (#PCDATA)>


Model niejednoznaczny

<!ELEMENT hasło (pojęcie, znaczenie?, etymologia?, znaczenie)>


<!ELEMENT hasło (pojęcie, ((znaczenie, (etymologia?, znaczenie)?) | (etymologia, znaczenie)))>


Elementy w dowolnej kolejności (1)

Konstrukcja SGML-owa:<!ELEMENT wielojęz - - (pol & ang)>


<!ELEMENT wielojęz ((pol, ang) | (ang, pol))>


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<!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)*>


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>


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?

<!ELEMENT NIP (#PCDATA)><!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<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>

Widoczność przestrzeni nazw

<?xml version="1.0"?><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>


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>


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.


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


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">


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"/>


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>


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>

Case studyXML 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.

• Projekt badawczo-rozwojowy prowadzony przez empolis Polska w 2000 roku.


Kolekcja Elektronicznych Dokumentów Ubezpieczeniowych

ZU S ZFB ...

1N r raportu

2O kres rozliczeniow y

01.I dentyfikator raportu

02.Kod terytorialny ...

...

I .D ane organ izacyjne

01.N I P

02.R EG ON

03.PESEL

...

I I .D ane identyfi kacyjne

płatnika składek

A.01.N azw isko

A.02.I m ię pierw sze

...

B .01.Kod tytułu ubezpieczenia

...

I I I .D ane dotyczące

osoby ubezpieczonej

01.D ata w ypełnienia

V.O św iadczen ie

płatnika składek

ZU S R CB ...

KEDUKolekcja E lektronicznych D okum entów Ubezpieczeniow ych


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ówSemantyczny: Składniowy:

DRZBdane-organizacyjne

termin-przys-deklident-deklaracji

dane-ident-platnikaNIPREGON

...

...

RCBdane-organizacyjne

dane-ident-platnika

...

...

DRZBDRZB.01

DRZB.01.01DRZB.01.02

DRZB.02DRZB.02.01DRZB.02.02

...

...

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

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


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

<!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;)?, ... )>


Przykład:reprezentacja w XML-u


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 www.empolis.pl Materiały Artykuły

poprawne modele zawartości. zarządzanie zmianami struktury

Documents