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

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)

<!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 (imie, 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='urn:loc.gov:books' xmlns:isbn='urn:ISBN:0-395-36341-6'> <title>Cheaper by the Dozen</title> <isbn:number>1568491379</isbn:number> <notes> <p xmlns='urn:w3-org-ns:HTML'> This is a <i>funny</i> book! </p> </notes></book>

Domyślna i lokalna przestrzeń nazw

Domyślna przestrzeń nazw:<reln xmlns="http://www.w3.org/TR/REC-MathML/"> <eq/><cn>2</cn><cn>4</cn></reln>

Lokalna przestrzeń 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

<book xmlns:xlink="http://www.w3.org/XML/XLink/0.9"> <chapter number="1" xlink:type="simple" xlink:href="..."> <title>Introduction</title> </chapter></book>

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:<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</data-ur> </nadawca> ...</podanie>

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

ZU S ZFB ...

1N r raportu

2O kres rozliczeniow y

01.I dentyfi kator raportu

02.Kod terytorialny ...

...

I .Dane organ izacyjne

01.N I P

02.R EG O N

03.PESEL

...

I I .Dane identyfikacyjne

płatn ika składek

A.01.N azw isko

A.02.I m ię pierw sze

...

B .01 .Kod tytułu ubezpieczenia

...

I I I .Dane dotyczące

osoby ubezpieczonej

01.Data w ypełnienia

V.O św iadczenie

płatn ika składek

ZU S R CB ...

KEDUKolekcja E lektronicznych Dokum entów U bezpieczeniow 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ów

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

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

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

Documents

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