Definiowanie typów dokumentów Część 2. XML Schema

Dlaczego DTD nie wystarcza? Zastosowania w integracji aplikacji – struktury danych: przeniesienie zadania sprawdzania poprawności z tworzonej aplikacji na narzędzie walidujące daje spore oszczędności. 60% tworzonego kodu dotyczy weryfikacji poprawności danych. Roger L. Costello, XML Schema Tutorial Cechy DTD: jedynie podstawowa kontrola nad strukturą dokumentów, bardzo ogólne metody definiowania częstości wystąpień, mało „obiektowe”, nierozszerzalne modele struktury. Taką kontrolę poprawności możemy oczywiście zaimplementować sami w kodzie naszej aplikacji (ewentualnie parametryzując aplikację przy pomocy atrybutów #FIXED), jest to jednak dość pracochłonne. Dobrze byłoby zrzucić walidację na parser XML. Standard XML Schema pozwala na definiowanie struktur dokumentów z dużo bardziej niż w DTD zaawansowaną kontrolą zawartości. 2004-10-21 Definiowanie typów dokumentów – część 2: XML Schema

DTD – XML Schema Wywodzi się z SGML-a Zaprojektowany na potrzeby XML-a Specyficzna składnia Składnia XML 10 typów danych 41+ typów danych Brak kontroli tekstowej zawartości elementów Zaawansowana kontrola tekstowej zawartości elementów Typowy mieszany model zawartości Możliwość definiowania własnych typów danych. 2004-10-21 Definiowanie typów dokumentów – część 2: XML Schema

Status XML Schema 15 lutego 1999: Dokument W3C opisujący wymagania stawiane przed nowym formatem: mechanizmy tworzenia struktury, typy proste, reguły przetwarzania. 2 maja 2001: XML Schema staje się oficjalną rekomendacją W3C: XML Schema Part 0: Primer, XML Schema Part 1: Structures, XML Schema Part 2: Datatypes. Obecnie: trwają prace nad wymaganiami do wersji 1.1 XML Schema. Przestrzeń nazw XML Schema: http://www.w3.org/2001/XMLSchema 2004-10-21 Definiowanie typów dokumentów – część 2: XML Schema

Definiowanie elementów i atrybutów <xsd:element name="osoba"> <xsd:complexType> <xsd:sequence> <xsd:element name="imie" type="xsd:string"/> <xsd:element name="nazwisko" type="xsd:string"/> <xsd:element name="plec" type="xsd:string"/> <xsd:element name="wiek" type="xsd:string"/> </xsd:sequence> <xsd:attribute name="id" type="xsd:ID"/> <xsd:attribute name="NIP" type="xsd:string"/> </xsd:complexType> </xsd:element> 2004-10-21 Definiowanie typów dokumentów – część 2: XML Schema

Określanie typu elementu/atrybutu Atrybut type: <xsd:element name="imie" type="xsd:string"/> Podelement complexType lub simpleType: <xsd:element name="osoba"> <xsd:complexType> ... </xsd:complexType> </xsd:element> 2004-10-21 Definiowanie typów dokumentów – część 2: XML Schema

Typy proste Wbudowane typy proste: string, boolean, integer, float, dateTime, ID, IDREF, CDATA, ... Typy proste definiują zbiory wartości atomowych (tzn. bez wewnętrznej struktury XML). Są nimi wszystkie typy wbudowane (np. liczba, napis, wartość logiczna), jak również typy stworzone na ich bazie (o tym później). Używa się ich do określania dopuszczalnych wartości atrybutów i zawartości elementów. Niektóre typy proste (ID, IDREF, CDATA) są zastrzeżone tylko dla atrybutów. 2004-10-21 Definiowanie typów dokumentów – część 2: XML Schema

Typy proste Tworzenie własnych typów prostych przy pomocy aspektów (facets): minInclusive, maxInclusive, minExclusive, maxExclusive, pattern, enumeration, list, union, length, minLength, maxLength. <xsd:element name="wiek"> <xsd:simpleType> <xsd:restriction base="xsd:integer"> <xsd:minInclusive value="0"/> <xsd:maxInclusive value="120"/> </xsd:restriction> </xsd:simpleType> </xsd:element> minInclusive, maxInclusive, minExclusive, maxExclusive – zawężają zakres dozwolonych wartości liczbowych. pattern – wzorzec wartości zgodny z podanym wyrażeniem regularnym. enumeration – typ wyliczeniowy. list – lista wartości typu prostego. length, minLength, maxLength – opowiednio wymagana, minimalna lub maksymalna długość napisu lub listy. 2004-10-21 Definiowanie typów dokumentów – część 2: XML Schema

Przykłady Lista wartości: Wyrażenia regularne: <xsd:simpleType name="LotteryNumbers"> <xsd:restriction> <xsd:simpleType> <xsd:list itemType="OneToNinetyNine"> </xsd:simpleType> <xsd:length value="6"/> </xsd:restriction> </xsd:simpleType> Wyrażenia regularne: <xsd:attribute name="NIP"> <xsd:simpleType> <xsd:restriction base="xsd:string"> <xsd:pattern value="\d{3}-\d{3}-\d{2}-\d{2}"/> </xsd:restriction> </xsd:simpleType> </xsd:attribute> 2004-10-21 Definiowanie typów dokumentów – część 2: XML Schema

Typy złożone Możliwość definiowania typów złożonych: sequence, choice, group, all. Kontrola użycia podelementów: minOccurs, maxOccurs. Kontrola użycia atrybutów: atrybut use o dopuszczalnych wartościach: required, optional lub prohibited. sequence - sekwencja wystąpień podelementów. chioce – alternatywa podelementów. group – grupowanie podelementów (nawiasy). all – wszystkie elementy muszą wystąpić, ale w dowolnej kolejności (konstrukcja dostępna w SGML DTD w postaci operatora &, lecz wycofana w XML DTD dla uproszczenia przetwarzania). Atrybuty minOccurs i maxOccurs określają liczby wystąpień elementów. Mogą one przyjmować wartości całkowite oraz specjalną wartość unbounded (nieograniczona liczba wystąpień). 2004-10-21 Definiowanie typów dokumentów – część 2: XML Schema

Kontrola użycia elementów i atrybutów <xsd:element name="osoba"> <xsd:complexType> <xsd:sequence> <xsd:element name="imie" type="xsd:string" minOccurs="1" maxOccurs="2"/> <xsd:element name="nazwisko" type="xsd:string"/> <xsd:element name="plec" type="xsd:string"/> <xsd:element name="wiek" type="xsd:string"/> </xsd:sequence> <xsd:attribute name="id" type="xsd:ID" use="required"/> <xsd:attribute name="NIP" type="xsd:string"/> </xsd:complexType> </xsd:element> 2004-10-21 Definiowanie typów dokumentów – część 2: XML Schema

Typ złożony, ale prosty <xsd:element name="roślina"> <xsd:complexType> <xsd:simpleContent> <xsd:extension base="xsd:string"> <xsd:attribute name="gatunek" type="xsd:string" use="required"/> </xsd:extension> </xsd:simpleContent> </xsd:complexType> </xsd:element> 2004-10-21 Definiowanie typów dokumentów – część 2: XML Schema

Model mieszany w XML Schema Możliwość kontroli ilości i kolejności podelementów: <xsd:element name="zeznanie"> <xsd:complexType mixed="true"> <xsd:sequence> <xsd:element name="poszkodowany" type="xsd:string"/> <xsd:element name="data" type="xsd:string"/> <xsd:element name="godzina" type="xsd:string" maxOccurs="2"/> </xsd:sequence> </xsd:complexType> </xsd:element> Model mieszany w DTD nie pozwala na ograniczenie ilości ani kolejności podelementów występujących w tekście. W XML Schema typ o modelu mieszanym definiuje się identycznie jak każdy inny typ. 2004-10-21 Definiowanie typów dokumentów – część 2: XML Schema

Typ zawartości jako samodzielny byt Oddzielenie deklaracji elementu od typu zawartości: typy anonimowe: <xsd:element name="osoby"> <xsd:complexType>...</xsd:complexType> </xsd:element> typy nazwane: <xsd:element name="osoba" type="osoba"/> ... <xsd:complexType name="osoba"> ... </xsd:complexType> W DTD deklaracja elementu definiuje jednocześnie typ jego zawartości. Jeśli chcemy przypisać ten sam model zawartości kilku elementom, to musimy wielokrotnie przepisać definicję modelu (ewentualnie upraszczając sobie życie przy pomocy encji parametrycznych). XML Schema oferuje byt pośredni – typ zawartości który definiujemy, nadając mu nazwę, a następnie przypisujemy do dowolnie wielu elementów/atrybutów. Dla uproszczenia, możemy zdefiniować typ bezpośrednio w deklaracji elementu (jak w DTD) i wtedy będzie to typ anonimowy. 2004-10-21 Definiowanie typów dokumentów – część 2: XML Schema

Inne możliwości XML Schema Dziedziczenie typów: rozszerzenie typu bazowego, zawężenie typu bazowego, typy abstrakcyjne. Grupy zamiennych elementów (substitution groups): możliwość zamiennego użycia elementów z grupy w dokumentach, przykładowe zastosowanie: schemat wielojęzyczny. Zaawansowana kontrola referencji: key – keyref: dowolna ilość kluczy: definiowane przy pomocy ścieżek XPath, wartości w ramach klucza muszą być unikatowe; referencja odwołuje się do konkretnego klucza: wartości referencji musi odpowiadać wartość klucza. Mechanizm typów pozwala znakomicie zmodularyzować schematy o skomplikowanej strukturze dzięk8i możliwości dziedziczenia, wzorowanej na dziedziczeniu dostępnym w obiektowych językach programowania. Mamy do dyspozycji takie konstrukcje, jak: typy abstrakcyjne (których nie można bezpośrednio przypisać do elementu, służą jedynie do dziedziczenia z nich konkretnych typów) czy konstrukcja final, zabraniająca dziedziczenia z danego typu. Dzięki grupom zamiennych elementów można np. przygotowywać wielojęzyczne schematy przeznaczone dla zastosowań międzynarodowych. Każdy element może mieć w takim schemacie wiele nazw w różnych językach. Kontrola referencji dostępna w DTD, przy pomocy atrybutów ID i IDREF, ma spore ograniczenia. Nie można zdefiniować wielu niezależnych zbiorów ID i odwoływać się do wybranego – kontrola obejmuje jedynie, czy IDREF wskazuje na dowolny ID w dokumencie. Klucze w XML Schema adresują ten problem. Dodatkowo, wartości klucza mogą być dowolne, mogą nawet być kombinacjami wartości kilku elementów i/lub atrybutów. 2004-10-21 Definiowanie typów dokumentów – część 2: XML Schema

Rozszerzanie typów <xsd:complexType name="Publikacja"> <xsd:sequence> <xsd:element name="Tytuł" type="xsd:string"/> <xsd:element name="Autor" type="xsd:string"/> <xsd:element name="RokPubl" type="xsd:year"/> </xsd:sequence> </xsd:complexType> <xsd:complexType name="Książka"> <xsd:complexContent> <xsd:extension base="Publikacja"> <xsd:sequence> <xsd:element name="ISBN" type="xsd:string"/> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> 2004-10-21 Definiowanie typów dokumentów – część 2: XML Schema

Czego nie można zamodelować w XML Schema? Brak walidacji kontekstowej, np.: zawartość elementu cena-netto jest mniejsza lub równa od zawartości elementu cena-brutto, jeżeli wartością atrybutu sposób-transportu jest powietrze, to element środek-transportu ma zawartość samolot lub balon. Metody walidacji kontekstowej: zaprogramowana w kodzie aplikacji, transformacja XSLT, Schematron: definiowanie własności, jakie ma spełniać dokument, komunikaty o błędach poprawności. Transformacje XSLT w ogólności służą do przekształcania dokumentu XML w inny dokument XML, HTML lub tekstowy. Można je jednak także wykorzystać do walidacji – tworząc transformację, która generuje dokument zawierający np. listę komunikatów o błędach walidacji (jeżeli dokument jest pusty, walidacja przebiegła pomyślnie). Można także wykorzystać dedykowany język Schematron, w którym zapisuje się asercje dotyczące dokumentu XML, tzn. warunki, które muszą być spełnione w pewnym kontekście. Darmowe narzędzie o tej samej nazwie pozwala przekształcać zbiory reguł Schematronowych do postaci transformacji XSLT. 2004-10-21 Definiowanie typów dokumentów – część 2: XML Schema

Schematron Język oparty na własnościach (asercjach), a nie na gramatyce: łatwe wyrażanie reguł walidacji kontekstowej, trudne, nieintuicyjne modelowanie struktury dokumentu, użyteczny w połączeniu ze zwykłą DTD lub schematem XML Schema. Status: obecna wersja: 1.5, rozpoczęty proces normalizacji (ISO/IEC 19757-3) dostępny draft specyfikacji ISO Schematron. Implementacja referencyjna: przekształcenie (generator) XSLT, dla zadanego schematu Schematronowego, generuje XSLT walidujący dokumenty. Dostępne kilkanaście implementacji. 2004-10-21 Definiowanie typów dokumentów – część 2: XML Schema

Język Schematron Własności ewaluowane w kontekście konkretnego węzła dokumentu: assert – własność, która musi być spełniona, report – własność, której spełnienie oznacza błąd. Określanie kontekstu i własności: wyrażenia XPath. Przykład: <rule context="towar"> <assert test="@wartosc = @cena * @liczba"> wartość = cena * liczba</assert> </rule> <rule context="faktura"> <report test="@platnosc != 'przelew' and ./przelew"> Przelew określony, a nie płacimy przelewem </report> </rule> Źródło: Czarnik, P., DTD, XML Schema – i co dalej?, Software 2.0, nr 6/2003 2004-10-21 Definiowanie typów dokumentów – część 2: XML Schema

RELAX NG REgular LAnguage description for XML – New Generation: składnia XML-owa, „bliska opisowi struktury w języku naturalnym”, wspiera typy danych (np. XML Schema Datatypes), atrybuty opisywane (prawie) tak samo, jak elementy, prosta technika modularyzacji: define / ref, model przetwarzania oparty na wyrażeniach regularnych. RELAX NG a inne języki: dostępne konstrukcje z SGML DTD, usunięte w XML DTD: elementy wymagane, ale bez określonego porządku, model mieszany – więcej możliwości; pozwala opisać niedostępne w XML Schema: niejednoznaczne i niedeterministyczne modele zawartości, modele zawartości wrażliwe na kontekst. 2004-10-21 Definiowanie typów dokumentów – część 2: XML Schema

Przykład DTD: RELAX NG: <!DOCTYPE addressBook [ <!ELEMENT addressBook (card*)> <!ELEMENT card (name, email)> <!ELEMENT name (#PCDATA)> <!ELEMENT email (#PCDATA)> ]> RELAX NG: <element name="addressBook" xmlns="http://relaxng.org/ns/structure/1.0"> <zeroOrMore> <element name="card"> <element name="name"> <text/> </element> <element name="email"> <text/> </element> </element> </zeroOrMore> </element> Źródło: RELAX NG Tutorial, http://www.relaxng.org/tutorial-20011203.html 2004-10-21 Definiowanie typów dokumentów – część 2: XML Schema

Przykład – niedeterminizm Konstrukcja zabroniona w XML Schema: <element name="name"> <choice> <text/> <group> <element name="firstName"><data type="token"/> </element> <optional> <element name="middleName"><data type="token"/> </element> </optional> <element name="lastName"><data type="token"/> </element> </group> </choice> </name> Źródło: RELAX NG Tutorial, http://www.relaxng.org/tutorial-20011203.html 2004-10-21 Definiowanie typów dokumentów – część 2: XML Schema

Przykład – niejednoznaczność Model niejednoznaczny. Nie istnieje równoważny model jednoznaczny. Nie da się zapisać w XML Schema. <element name="even-odd"> <zeroOrMore> <ref name="odd"/> <ref name="even"/> </zeroOrMore> <optional> </optional> </element> Źródło: Vlist, E. van der, RELAX NG, http://books.xmlschemata.org/relaxng 2004-10-21 Definiowanie typów dokumentów – część 2: XML Schema

Examplotron Definiowanie schematu „przez przykład”: Ograniczenia: instancja dokumentu definiuje schemat, konwencje, np.: powtórzenie elementu oznacza dowolną krotność, przykładowa zawartość elementu definiuje typ. Ograniczenia: „przez przykład” nie można wyrazić konstrukcji abstrakcyjnych, dodatkowa, specyficzna składnia pozwala na dokładniejszą kontrolę struktury. Status: projekt na wczesnym etapie rozwoju (wersja 0.7), dostępne narzędzie: compile.xsl – przekształca schematy Examplotronowe do RELAX NG. 2004-10-21 Definiowanie typów dokumentów – część 2: XML Schema

Examplotron – przykład <?xml version="1.0" encoding="UTF-8"?> <order date="2003-02-01" eg:content="eg:interleave" xmlns:eg="http://examplotron.org/0/"> <eg:attribute name="no">1234 </eg:attribute> <quantity>1</quantity> <ref>AZERTY</ref> <ref>ZXCVBN</ref> <item>Tee shirt</item> <price unit="USD">10.</price> </order> atrybut opcjonalny typu data element powtarzalny atrybut wymagany typu liczba dowolna kolejność podelementów 2004-10-21 Definiowanie typów dokumentów – część 2: XML Schema

Gdzie szukać dalej W3C Architecture Domain: XML Schema www.w3.org/XML/Schema Costello, R., XML Schema Tutorial www.xfront.com/xml-schema.html RELAX NG Home Page www.relaxng.org Schematron www.schematron.com Examplotron examplotron.org Vlist, E. van der, Comparing XML Schema Languages www.xml.com/pub/a/2001/12/12/schemacompare.html Vlist, E. van der, Relax NG Compared www.xml.com/pub/a/2002/01/23/relaxng.html Czarnik, P., DTD, XML Schema – i co dalej?  Software 2.0, nr 6/2003, Wydawnictwo Software 2004-10-21 Definiowanie typów dokumentów – część 2: XML Schema