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

Prezentacja na temat: "Definiowanie typów dokumentów Część 2. XML Schema"— Zapis prezentacji:

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

2 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. Definiowanie typów dokumentów – część 2: XML Schema

3 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. Definiowanie typów dokumentów – część 2: XML Schema

4 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: Definiowanie typów dokumentów – część 2: XML Schema

5 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> Definiowanie typów dokumentów – część 2: XML Schema

6 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> Definiowanie typów dokumentów – część 2: XML Schema

7 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. Definiowanie typów dokumentów – część 2: XML Schema

8 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. Definiowanie typów dokumentów – część 2: XML Schema

9 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> Definiowanie typów dokumentów – część 2: XML Schema

10 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ń). Definiowanie typów dokumentów – część 2: XML Schema

11 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> Definiowanie typów dokumentów – część 2: XML Schema

12 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> Definiowanie typów dokumentów – część 2: XML Schema

13 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. Definiowanie typów dokumentów – część 2: XML Schema

14 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. Definiowanie typów dokumentów – część 2: XML Schema

15 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. Definiowanie typów dokumentów – część 2: XML Schema

16 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> Definiowanie typów dokumentów – część 2: XML Schema

17 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. Definiowanie typów dokumentów – część 2: XML Schema

18 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 ) 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. Definiowanie typów dokumentów – część 2: XML Schema

19 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 wartość = cena * liczba</assert> </rule> <rule context="faktura"> <report != '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 Definiowanie typów dokumentów – część 2: XML Schema

20 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. Definiowanie typów dokumentów – część 2: XML Schema

21 Przykład DTD: RELAX NG:
<!DOCTYPE addressBook [ <!ELEMENT addressBook (card*)> <!ELEMENT card (name, )> <!ELEMENT name (#PCDATA)> <!ELEMENT (#PCDATA)> ]> RELAX NG: <element name="addressBook" xmlns=" <zeroOrMore> <element name="card"> <element name="name"> <text/> </element> <element name=" "> <text/> </element> </element> </zeroOrMore> </element> Źródło: RELAX NG Tutorial, Definiowanie typów dokumentów – część 2: XML Schema

22 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, Definiowanie typów dokumentów – część 2: XML Schema

23 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, Definiowanie typów dokumentów – część 2: XML Schema

24 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. Definiowanie typów dokumentów – część 2: XML Schema

25 Examplotron – przykład
<?xml version="1.0" encoding="UTF-8"?> <order date=" " eg:content="eg:interleave" xmlns:eg=" <eg:attribute name="no"> </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 Definiowanie typów dokumentów – część 2: XML Schema

26 Gdzie szukać dalej W3C Architecture Domain: XML Schema
Costello, R., XML Schema Tutorial RELAX NG Home Page Schematron Examplotron examplotron.org Vlist, E. van der, Comparing XML Schema Languages Vlist, E. van der, Relax NG Compared Czarnik, P., DTD, XML Schema – i co dalej?  Software 2.0, nr 6/2003, Wydawnictwo Software Definiowanie typów dokumentów – część 2: XML Schema