2 XML Schema: johdanto ja rakenteiden perusteet

Transkriptio

1 2 XML Schema: johdanto ja rakenteiden perusteet Kun XML-dokumentteja tarkastellaan kommunikoivien järjestelmien välisinä viesteinä, on tärkeää että viestiformaatista on sovittu täsmällisesti. Yleisemmin tarkasteltuna tarvitaan paitsi (universaaleja) sanastoja, myös (universaaleja) skeemoja sekä (universaaleja) datatyyppejä (näihin palaamme myöhemmin). Kuten tunnettua, XML DTD ei tarjoa riittävää menetelmää em. sovellusten toteuttamiseen. Erityisesti, XML DTD ei kykene (hyvin) käsittelemään nimiavaruuksia, eikä tarjoa käyttökelpoista menetelmää datatyyppien määrittelyyn. XML Schema eli XML-skeemat esittelee keinon määritellä tietorakenteiden tyyppi URI-nimiin pohjautuviin nimiavaruuksiin vedoten (rajoitteina), sekä tarjoaa keinon monipuolisten datatyyppien määrittelyyn. Määrityksille löytyy jatkossa käyttöä myös varsinaisten XML-viestiformaattien ulkopuolella. 16

2 2.1 Välisoitto Pyrkimys kohti tiedon mekaanista hallintaa johtaa väistämättä kohti tiedon täsmällistä kuvailua Mutta ennen kuin kuvailu onnistuu, pitää tietoa osata mallintaa (ymmärrys vs. formalisointi vs. mekaaninen käsittely) Kysymys mitä mallinnetaan, miten ja millä tarkkuudella, jää lopulta sovelluskohtaisesti ratkaistavaksi 17

3 2.2 Esimerkki (1/2) Tarkastellaan esimerkin vuoksi tilannetta jossa halutaan välittää tilaustiedoista XML-muodossa (Ks. XML Schema Primer & po.xml) <?xml version="1.0"?> <purchaseorder orderdate=" "> <shipto country="us"> <name>alice Smith</name> <street>123 Maple Street</street> <city>mill Valley</city> <state>ca</state> <zip>90952</zip> </shipto> <billto country="us"> <name>robert Smith</name> <street>8 Oak Avenue</street> <city>old Town</city> <state>pa</state> <zip>95819</zip> </billto>... 18

4 2.3 Esimerkki (1/2), jatkuu <comment>hurry, my lawn is going wild!</comment> <items> <item partnum="872-aa"> <productname>lawnmower</productname> <quantity>1</quantity> <USPrice>148.95</USPrice> <comment>confirm this is electric</comment> </item> <item partnum="926-aa"> <productname>baby Monitor</productName> <quantity>1</quantity> <USPrice>39.98</USPrice> <shipdate> </shipdate> </item> </items> </purchaseorder> Tuttu rakenne, XML-dokumentti (so. nimetty dokumenttientiteetti) Tunnista osat... 19

5 2.4 Peruskäsitteitä ja huomioita Elementti on tyypiltään ns. kompleksinen jos sillä on lapsielementtejä tai attribuutteja (Complex Type), muutoin ns. yksinkertainen (Simple Type) - yksinkertaiset tyypit ovat käytännössä "datatyyppejä" tai listoja (mutta huomaa että yksinkertainenkin tyyppi voidaan määritellä itse) Attribuutit ovat aina tyypiltään yksinkertaisia Yksittäistä dokumenttia (tarkemmin: dokumenttiluokan esiintymää, Instance) tutkimalla ei selviä kaikki dokumentin tulkinnassa tarvittava tieto. Erityisesti, emme voi päätellä - minkälaisen rakenteen puitteissa tietoa on sallittua kuvata (vaihtelu) - mitä datatyyppejä rakenne sisältää (esim. päivämäärä) - mitä oletusarvoja tms. dokumentin tulkinnassa tarvitaan... tarvitsemme siis skeematietoa tulkinnan tueksi Eräs tuttu "skeemakieli" dokumentin tyypin määrittämiseen on XML DTD 20

6 2.5 Esimerkki: XML DTD (1/3) Lisäämme dokumenttiin eksplisiittisen tyyppitiedon: <?xml version="1.0"?> <!DOCTYPE purchaseorder SYSTEM "po.dtd"> <purchaseorder orderdate=" ">...</purchaseorder> Dokumentti voi nyt olla validi jos se noudattaa ilmoittamaansa tyyppimäärittelyä XML DTD ei kuitenkaan pysty mallintamaan tietoa kovin yksityiskohtaisesti Eräs mallinnus (po.dtd): <!-- po.dtd ON > <!ENTITY % USAddress "name,street,city,state,zip"> <!ENTITY % shipattrs "country NMTOKEN #FIXED 'US'"> <!ENTITY % itemattrs "partnum NMTOKEN #REQUIRED"> <!ELEMENT purchaseorder (shipto, billto, comment?, items)> <!ATTLIST purchaseorder orderdate CDATA #REQUIRED> 21

7 <!ELEMENT shipto (%USAddress;)> <!ATTLIST shipto %shipattrs;> <!ELEMENT billto (%USAddress;)> <!ATTLIST billto %shipattrs;> <!ELEMENT items (item*)> <!ELEMENT item (productname, quantity, USPrice, comment?, shipdate?)> <!ATTLIST item %itemattrs;> <!ELEMENT name (#PCDATA)> <!ELEMENT street (#PCDATA)> <!ELEMENT city (#PCDATA)> <!ELEMENT state (#PCDATA)> <!ELEMENT zip (#PCDATA)> <!ELEMENT comment (#PCDATA)> <!ELEMENT productname (#PCDATA)> <!ELEMENT quantity (#PCDATA)> <!ELEMENT USPrice (#PCDATA)> <!ELEMENT shipdate (#PCDATA)> <!ELEMENT partnum (#PCDATA)> 22

8 2.6 Esimerkki: XML DTD (3/3) Huomioita: - rajoittunut tietomalli, elementtien ja attribuuttien määrittelyn epäsymmetria (esim. #PCDATA vs. CDATA/NMTOKEN) - erikoinen syntaksi, eikä mahdollista määritellä esim. uudelleenkäytettävää elementin tietomallia muutoin kuin parametrientiteettien avulla - ei tukea nimiavaruuksille (ei tosin tässä esimerkissä haittaa) - ei datatyyppejä (esim. "päivämäärä") - dokumentointi päälleliimattujen kommenttien avulla - mutta idea melko yksinkertainen ja esitys tiivis (mieti mitä näin jää kuitenkin sanomatta) Rakennetaan seuraavaksi "vastaava" mutta rikkaampi tyyppimääritys/tietomalli XML-skeemamäärittelyn avulla... 23

9 2.7 XML Schema Suositus XML-skeemoista täydentää XML-perhettä yleiskäyttöisellä teksti- ja viestiformaattien mallinnuskielellä (vrt. tietokantasuunnittelu) 1. suositus vuonna 2001, määrittelyteknisiä päivityksiä 2004 Osat: - XML Schema Part 0: Primer (Second Edition),... Part 1: Structures ja Part 2: Datatypes Kommentteja - "yleinen näkemys" on, että suositus on hyvin ilmaisuvoimainen, mutta "tarpeettoman" monimutkainen ja hankala käyttää - seuraa DTD:n linjaa hyvässä ja pahassa (skeeman tulkinta saattaa esim. muuttaa dokumentin tietosisältöä oletusarvojen yms. takia) - jako rakenteiden ja datatyyppien välillä on hyvä; osaa 2 käytetään laajasti myös erillään osasta 1 (myös tällä kurssilla) 24

10 2.8 Esimerkki, mallinnus XML-skeeman avulla Ks. (po.xsd) <xsd:schema xmlns:xsd=" <xsd:annotation> <xsd:documentation xml:lang="en"> Purchase order schema for Example.com. Copyright 2000 Example.com. All rights reserved. </xsd:documentation> </xsd:annotation> <xsd:element name="purchaseorder" type="purchaseordertype"/> <xsd:element name="comment" type="xsd:string"/> <xsd:complextype name="purchaseordertype"> <xsd:sequence> <xsd:element name="shipto" type="usaddress"/> <xsd:element name="billto" type="usaddress"/> <xsd:element ref="comment" minoccurs="0"/> 25

11 <xsd:element name="items" type="items"/> </xsd:sequence> <xsd:attribute name="orderdate" type="xsd:date"/> </xsd:complextype> <xsd:complextype name="usaddress"> <xsd:sequence> <xsd:element name="name" type="xsd:string"/> <xsd:element name="street" type="xsd:string"/> <xsd:element name="city" type="xsd:string"/> <xsd:element name="state" type="xsd:string"/> <xsd:element name="zip" type="xsd:decimal"/> </xsd:sequence> <xsd:attribute name="country" type="xsd:nmtoken" fixed="us"/> </xsd:complextype> <xsd:complextype name="items"> <xsd:sequence> <xsd:element name="item" minoccurs="0" maxoccurs="unbounded"> <xsd:complextype> <xsd:sequence> 26

12 <xsd:element name="productname" type="xsd:string"/> <xsd:element name="quantity"> <xsd:simpletype> <xsd:restriction base="xsd:positiveinteger"> <xsd:maxexclusive value="100"/> </xsd:restriction> </xsd:simpletype> </xsd:element> <xsd:element name="usprice" type="xsd:decimal"/> <xsd:element ref="comment" minoccurs="0"/> <xsd:element name="shipdate" type="xsd:date" minoccurs="0"/> </xsd:sequence> <xsd:attribute name="partnum" type="sku" use="required"/> </xsd:complextype> </xsd:element> </xsd:sequence> </xsd:complextype> <!-- Stock Keeping Unit, a code for identifying products --> <xsd:simpletype name="sku"> <xsd:restriction base="xsd:string"> <xsd:pattern value="\d{3}-[a-z]{2}"/> 27

13 </xsd:restriction> </xsd:simpletype> </xsd:schema> Viittaus ko. skeematiedostoon voidaan vihjeenä liittää XML-dokumentiin (vaan ei ole pakko), esim. (nyt ei määriteltyä nimiavaruutta): <purchaseorder orderdate=" " xmlns:xsi=" xsi:nonamespaceschemalocation="po.xsd">... Tällöin validointi (skeeman suhteen) esim. Xerces-parserilla (ks. onnistuu komennolla: java -classpath... dom.counter -s -v po.xml Kokeile verkossa, ks. esim. 28

14 2.9 Validointi: huomautuksia Dokumentti validoidaan skeeman suhteen periaatteessa samoin kuten DTD:nkin tapauksessa. Keskeisiä eroja: - skeemojen kielioppi on melko monimutkainen ja laajentaa DTD:n määrittelyä käsitteellisesti (ei kuitenkaan korvaa [yleisiä] entiteettejä) -...mahdollisuus rajata dokumenttiluokan rakenne paljon tarkemmin - XML-dokumentista (ns. esiintymästä, instance) ei ole pakko löytyä suoraa viittausta validoinnissa käytettävään skeemaan (joskin voi löytyä) jäsennin voi pakottaa validoinnin - validointi voi kiinnittyä erikseen nimetyn skeematiedoston ohella myös nimiavaruuden perusteella "Jokainen DTD voidaan esittää XML-skeemana muttei toisinpäin" Huom. XML Schema ei kuitenkaan ole "yleisin/vahvin ajateltavissa oleva" XML-skeemakieli määrityksen nimi (yleisnimi) on siten harhaanjohtava! 29

15 2.10 XML-skeeman yleisrakenne Skeema on XML-dokumentti (tai useita dokumentteja) joka määrittelee XMLdokumenttiluokan keskeisesti rajoitteiden ja oletusarvojen varassa: schema include import redefine annotation simpletype complextype element attribute attributegroup group Käytännössä skeema voi efektiivisesti tarkoittaa kaikkia niitä skeemamäärityksiä johon tarkasteltavan dokumentin esiintymäosa viittaa (evaluointi nimiavaruuksien perusteella) 30

16 2.11 Tyyppimäärittelyn perusteet (1/2) Tyyppimäärittely on elementtien ja attribuuttien tapauksessa oleellisesti samanlainen - attribuuteilla ei kuitenkaan voi olla sisältönä elementtejä tai toisia attribuutteja, niinpä attribuuttien tyypin on aina oltava yksinkertainen Elementin tai attribuutin tyyppi voidaan pääsääntöisesti määritellä kahdella tavalla. Ensimmäinen tapa on määritellä tyyppi implisiittisesti elementin tai attribuutin nimen ja esittelyn yhteydessä (ns. Anonymous Type): <xsd:element name="quantity"> <xsd:simpletype> <xsd:restriction base="xsd:positiveinteger"> <xsd:maxexclusive value="100"/> </xsd:restriction> </xsd:simpletype> </xsd:element> 31

17 2.12 Tyyppimäärittelyn perusteet (2/3) Toinen tapa on määritellä nimetty tietotyyppi johon elementin tai attribuutin esittelyssä viitataan -...tällöin siihen voidaan myös viitata useasti Esimerkki, nimetty yksinkertainen tyyppi: <xsd:attribute name="partnum" type="sku" use="required"/>... <xsd:simpletype name="sku"> <xsd:restriction base="xsd:string"> <xsd:pattern value="\d{3}-[a-z]{2}"/> </xsd:restriction> </xsd:simpletype> 32

18 2.13 Tyyppimäärittelyn perusteet (3/3) Esimerkki, nimetty kompleksinen tyyppi: <xsd:element name="shipto" type="usaddress"/> <xsd:element name="billto" type="usaddress"/>... <xsd:complextype name="usaddress"> <xsd:sequence> <xsd:element name="name" type="xsd:string"/> <xsd:element name="street" type="xsd:string"/> <xsd:element name="city" type="xsd:string"/> <xsd:element name="state" type="xsd:string"/> <xsd:element name="zip" type="xsd:decimal"/> </xsd:sequence> <xsd:attribute name="country" type="xsd:nmtoken" fixed="us"/> </xsd:complextype> Vertaa vastaavaa määrittelyä DTD:n ja parametrientiteetin avulla 33

19 2.14 Elementtien määrittely, perusteet Elementtien määrittely tapahtuu analogisesti DTD:n tavoin (esim. kertojat), joskin syntaksi on uusi ja mukana on lisämääreitä, esim.: <xsd:element name="article" type="xsd:string" minoccurs="0" maxoccurs="unbounded" processcontents="strict" default="hello World!" nillable="true" /> Yleisessä tapauksessa määreet valitaan 14 attribuutin joukosta. Esimerkki uudesta piirteestä: nillable <article xsi:nil="false"/> Esittelyn yhteydessä voidaan viitata (type) paitsi nimettyyn tietotyyppiin (esim. xsd:string, USAdress), myös toisaalla määriteltyyn elementtiin (ref): <xsd:element ref="comment" minoccurs="0"/> Huomaa että skeema ei määrittele mikä päätasolla luetelluista elementeistä (global) on dokumentin esiintymän juurielementti, ts. skeemamäärittely on aina suhteellinen (parseri toki aina tietää esiintymän juurielementin!) 34

20 2.15 Validoinnin tarkkuus Elementin tyyppimäärittelyn attribuutti processcontents (skip lax strict) tarjoaa keinon sisällyttää dokumentteihin (wf) osia joiden tyyppi voi olla tietyssä mielessä epämääräinen, vrt. esim. <element name="htmlexample"> <complextype> <sequence> <any namespace=" minoccurs="1" maxoccurs="unbounded" processcontents="skip"/> </sequence> </complextype> </element> Arvo skip: Elementin sisältöä ei edes yritetä validoida Arvo lax: Elementin sisältö validoidaan vain siltä osin kuin se onnistuu (eli ilmoitettuihin nimiavaruuksiin vedoten) Arvo strict (oletus): Elementin tulee olla validoitavissa kokonaisuudessaan 35

21 2.16 Elementtien tietomallin määrittely: "DTD:stä tutut" Tietomalli rakennetaan keskeisesti operaattorien sequence, choice, group ja all avulla, esim. "(((shipto, billto) singleusaddress), comment?, items)" : <xsd:complextype name="purchaseordertype"> <xsd:sequence> <xsd:choice> <xsd:group ref="shipandbill"/> <xsd:element name="singleusaddress" type="usaddress"/> </xsd:choice> <xsd:element ref="comment" minoccurs="0"/> <xsd:element name="items" type="items"/> </xsd:sequence> <xsd:attribute name="orderdate" type="xsd:date"/> </xsd:complextype> <xsd:group id="shipandbill"> <!--HUOM: group@minoccures, maxoccurs.. --> <xsd:sequence> <xsd:element name="shipto" type="usaddress"/> <xsd:element name="billto" type="usaddress"/> </xsd:sequence> </xsd:group> 36

22 2.17 Elementtien tietomallin määrittely: all Operaattori all: luetellut elementit esiintyvät missä tahansa järjestyksessä Esim. <xsd:complextype name="purchaseordertype"> <xsd:all> <xsd:element name="shipto" type="usaddress"/> <xsd:element name="billto" type="usaddress"/> <xsd:element ref="comment" minoccurs="0"/> <xsd:element name="items" type="items"/> </xsd:all> <xsd:attribute name="orderdate" type="xsd:date"/> </xsd:complextype> Käyttöön (lapsellisia :-) rajoituksia: käytössä vain päätasolla (ei ryhmittelyyn tietomallin sisällä), lapset eivät saa olla ryhmiä, lapsille sallittu vain esiintymistä kuvaavat kertoimet 0 tai 1,... 37

23 2.18 Attribuuttien liittäminen elementtiin (1/2) Tarkastellaan ensin elementtiä jolla sisältönä vain merkkidataa...esim... <internationalprice currency="eur">423.46</internationalprice>...tapahtuu siten että "laajennetaan" valittua tietotyyppiä attribuutilla: <xsd:element name="internationalprice"> <xsd:complextype> <xsd:simplecontent> <xsd:extension base="xsd:decimal"> <xsd:attribute name="currency" type="xsd:string"/> </xsd:extension> </xsd:simplecontent> </xsd:complextype> </xsd:element> Jos attribuutteja on useita, ne vain luetellaan jossakin järjestyksessä 38

24 2.19 Attribuuttien liittäminen elementtiin (2/2) Lapsielementtejä omaavien elementtien attribuuttien esittelyt luetellaan heti elementin tietomallin jälkeen complextype-elementin sisällä: <element name="item"> <complextype> <sequence> <xsd:element ref="comment" minoccurs="0"/> <xsd:element name="items" type="items"/> </sequence> <attribute name="desc" type="xsd:string"/> <!-- jne. --> </complextype> </element>...sama pätee yhdistelmäsisältöisille elementeille 39

25 2.20 Yhdistelmäsisältöinen elementti (1/2) Yhdistelmäsisältöinen tietomalli ilmoitetaan attribuutilla mixed: <xsd:element name="letterbody"> <xsd:complextype mixed="true"> <xsd:sequence> <xsd:element name="salutation"> <xsd:complextype mixed="true"> <xsd:sequence> <xsd:element name="name" type="xsd:string"/> </xsd:sequence> </xsd:complextype> </xsd:element> <xsd:element name="quantity" type="xsd:positiveinteger"/> <xsd:element name="productname" type="xsd:string"/> <xsd:element name="shipdate" type="xsd:date" minoccurs="0"/> <!-- etc. --> </xsd:sequence> </xsd:complextype> </xsd:element> 40

26 2.21 Yhdistelmäsisältöinen elementti (2/2) Sallittu esiintymä: <letterbody> <salutation>dear Mr.<name>Robert Smith</name>.</salutation> Your order of <quantity>1</quantity> <productname>baby Monitor</productName> shipped from our warehouse on <shipdate> </shipdate>.... </letterbody> Huom. toisin kuin DTD, XML-skeema voi rajoittaa yhdistelmäsisältöisen elementin lapsielementtien esiintymisjärjestystä ja lukumäärää (ts. valinnat sequence, choice, all ovat merkitseviä) 41

27 2.22 Tyhjä elementti Kaikille elementeillä ei ole sisältöä. Tyhjän elementin määrittely hoidetaan (hieman erikoisesti) rajoittimella Käytössä on lyhennemerkintä: <xsd:element name="br"> <xsd:complextype/> </xsd:element> Jos tyhjällä elementillä on attribuutteja (kuten yleensä), tarvitaan kompleksinen tietotyyppi: <xsd:element name="internationalprice"> <xsd:complextype> <xsd:complexcontent> <xsd:restriction base="xsd:anytype"> <xsd:attribute name="currency" type="xsd:string"/> <xsd:attribute name="value" type="xsd:decimal"/> </xsd:restriction> </xsd:complexcontent> </xsd:complextype> </xsd:element> 42

28 2.23 Rajoitteeton elementti(tyyppi): anytype Jos kaikki (merkki- ja lapsielementtisisältö) käy, voidaan määritellä <xsd:element name="anything" type="xsd:anytype"/> Potentiaalinen mallinnuksen vaaranpaikka piilee siinä, että tämä on typeattribuutin oletusarvo, ts. samaa tarkoittaa myös <xsd:element name="anything"/> Huom. - DTD-mallinnuksessa ANY-tyyppinen elementti on (kukaties) käyttökelpoinen kun halutaan määritellä DTD jossa on "reikiä" (so. kohtia joista voi löytyä "mitä tahansa") -...skeemojen tapauksessa sellaisen elementin tietomalli jota ei haluta määritellä "tässä ja nyt" voidaan kuitenkin esittää järkevämmin kuin anytype-tyyppisenä (nimiavaruuksiin vedoten, vrt. esim. processcontents) 43

29 2.24 Attribuuttien määrittely Attribuutit määritellään siis kompleksisten tyyppien osana: <xsd:element name="internationalprice"> <xsd:complextype> <xsd:simplecontent> <xsd:extension base="xsd:decimal"> <xsd:attribute name="currency" type="xsd:string"/> </xsd:extension> </xsd:simplecontent> </xsd:complextype> </xsd:element> Attribuuttien määrittelyyn liittyvät keskeisesti attribuutit - use: optional required prohibited (oletuksena arvo optional) - default: oletusarvon ilmoittaminen - fixed: pakotettu arvo - minoccurs/maxoccurs: esiintymiskerrat (0/1) 44

30 2.25 Vaihtoehtoisten attribuuttiarvojen määrittely Tuttu <!ATTLIST X shipby (air land any) #IMPLIED> määritellään taas rajoitteiden avulla <xsd:attribute name="shipby"> <xsd:simpletype> <xsd:restriction base="xsd:string"> <xsd:enumeration value="air"/> <xsd:enumeration value="land"/> <xsd:enumeration value="any"/> </xsd:restriction> </xsd:simpletype> </xsd:attribute> Datatyyppien käyttö laajentaa merkittävästi tapaa jolla attribuuttien (tai elementtien!) arvoalueita voidaan määritellä Yleisesti arvo voidaan määritellä esim. säännönmukaisen lausekkeen avulla (tähän palataan myöhemmin) 45

31 2.26 Attribuuttiryhmien määrittely Attribuutit liittyvät elementteihin, mutta skeemoissa ne voidaan määritellä myös viitattavina ryhminä - kompleksisen tietotyypin avulla tai attribuuttiryhmien avulla: <xsd:element name="item" minoccurs="0" maxoccurs="unbounded"> <xsd:complextype> <xsd:sequence> <xsd:element name="productname" type="xsd:string"/>... </xsd:sequence> <xsd:attributegroup ref="itemdelivery"/> </xsd:complextype> </xsd:element> <xsd:attributegroup id="itemdelivery"> <xsd:attribute name="partnum" type="sku" use="required"/> <xsd:attribute name="weightkg" type="xsd:decimal"/>.. </xsd:attributegroup> 46

32 2.27 Nimiavaruuksista Eräs keskeisimmistä skeemojen piirteistä on tuki nimiavaruuksille Skeemamäärittely voi sisältää ns. kohdenimiavaruuden (target namespace) johon skeeman ajatellaan esittelevän sanastonsa <schema xmlns=" xmlns:po=" targetnamespace=" elementformdefault="unqualified" attributeformdefault="unqualified"> <!--...Default oletusarvot-->... Nimiavaruuksien syntaksi sallii kuitenkin saman skeeman määrittelyn usein eri tavoin - skeemat kuitenkin esim. (ikävästi) sotkevat nimiavaruuksien prefiksinimet asiasisällön kanssa Määrittelyssä kannattaa tietenkin pyrkiä selkeyteen, hallittavuuteen ja yksinkertaisuuteen 47

33 2.28 Esimerkki: Purchase Order nimiavaruuksilla (1/2) <schema xmlns=" xmlns:po=" targetnamespace=" elementformdefault="unqualified" attributeformdefault="unqualified"> <element name="purchaseorder" type="po:purchaseordertype"/> <element name="comment" type="string"/> <complextype name="purchaseordertype"> <sequence> <element name="shipto" type="po:usaddress"/> <element name="billto" type="po:usaddress"/> <element ref="po:comment" minoccurs="0"/> <!-- etc. --> </sequence> <!-- etc. --> </complextype> 48

34 2.29 Esimerkki: Purchase Order nimiavaruuksilla (2/2) <complextype name="usaddress"> <sequence> <element name="name" type="string"/> <element name="street" type="string"/> <!-- etc. --> </sequence> </complextype> <!-- etc. --> </schema> Kommentteja: - huomaa skeeman oletusnimiavaruus (olisi voitu käyttää prefiksejä!) - viittaukset skeeman sisällä nimiavaruuksiin vedoten Esimerkkiskeema on käytännössä hieman erikoinen yhdistelmä nimiavaruuteen sidottuja (qualified) ja ilman nimiavaruutta (unqualified) sovellettavia nimiä 49

35 2.30 Esimerkkidokumentti, osa 1 <?xml version="1.0"?> <apo:purchaseorder xmlns:apo=" orderdate=" "> <shipto country="us"> <name>alice Smith</name> <street>123 Maple Street</street> <!-- etc. --> </shipto> <billto country="us"> <name>robert Smith</name> <street>8 Oak Avenue</street> <!-- etc. --> </billto> <apo:comment>hurry, my lawn is going wild!</apo:comment> <!-- etc. --> </apo:purchaseorder> Mieti mihin nimiavaruuteen elementit ja attribuutit kuuluvat! Ts. Prefiksillä apo koodatut nimet toimivat nyt globaaleina niminä 50

36 2.31 Esimerkki: Purchase Order, toinen versio Pakotetaan sitten nimiavaruus koko dokumenttiin: <schema xmlns=" xmlns:po=" targetnamespace=" elementformdefault="qualified" attributeformdefault="unqualified"> <element name="purchaseorder" type="po:purchaseordertype"/> <element name="comment" type="string"/> <complextype name="purchaseordertype"> <!-- etc. --> </complextype> <!-- etc. --> </schema> Ts. nyt ero piilee siinä, että kaikki elementit (joita ei erikseen muuksi kvalifioida) osoitetaan kohdenimiavaruuteen 51

37 2.32 Esimerkkidokumentti, versio 2 <?xml version="1.0"?> <purchaseorder xmlns=" orderdate=" "> <shipto country="us"> <name>alice Smith</name> <street>123 Maple Street</street> <!-- etc. --> </shipto> <billto country="us"> <name>robert Smith</name> <street>8 Oak Avenue</street> <!-- etc. --> </billto> <comment>hurry, my lawn is going wild!</comment> <!-- etc. --> </purchaseorder> Esiintymäosassa nimiavaruus voidaan ilmoittaa taas usein eri tavoin, siis myös kvalifioitujen nimien avulla (mv. prefiksejä käyttäen) 52

38 2.33 Kvalifioidut attribuutit Nimiavaruutta ei "yleensä" määritellä attribuuteille (paitsi standardoiduille globaaleille attribuuteille, vrt. esim. xlink:href, xi:include, tms.) Attribuutin nimiavaruus voidaan toki skeemassa kuitenkin pakottaa: <schema xmlns=" xmlns:po=" targetnamespace=" elementformdefault="qualified" attributeformdefault="unqualified">... <element name="secure"> <complextype> <sequence>... </sequence> <attribute name="publickey" type="base64binary" form="qualified"/> </complextype> </element> </schema> Tällöin dokumentin esiintymäosassa attribuutti publickey on pakko kvalifioida (nyt siis nimiavaruuteen 53

39 2.34 Lopuksi On aina suositeltavaa käyttää kvalifioituja nimiä itse XML Schema -sanaston yhteydessä, esim. xsd:element (vrt. oletusnimiavaruuden käyttö) Nimiavaruudet rikastavat tyyppimäärittelyn mahdollisuuksia, erityisesti: - ei pakotettua juurielementtiä -...niinpä eri nimiavaruuksiin pohjautuvien määrittelyjen yhdistely on mahdollista -... ja esim. tietyn skeeman mukaisten elementtirakenteiden upottaminen osaksi toisia skeemoja on mahdollista Skeema ja DTD voivat olla käytössä myös rinnakkain, - yleensä "järkevää" käyttöä on sieventää esim. nimiavaruuksia entiteettien avulla yms. 54