4 XML Schema: tyyppihierarkiat ja avaimet

Transkriptio

1 4 XML Schema: tyyppihierarkiat ja avaimet Skeemat mahdollistavat yksinkertaisten rakenteiden ja tietotyyppien määrittelyn ohella myös muutakin käyttökelpoista. Erityisesti: - myös kompleksisia tyyppejä voidaan johtaa olemassa olevista tyypeistä, - skeemojen osat voivat sisältää korvattavia osia, skeemoja voidaan määritellä uudelleen, ja - skeemat voivat asettaa vaatimuksia esiintymän tietosisällön yksikäsitteisyydelle (avainten tavoin). Tarkastelemme näitä seuraavaksi. Paitsi että opimme lukemaan toisten kirjoittamia skeemoja, tarjoavat määritykset myös "selityksen" skeemojen aluksi hankalalta näyttävälle määrittelyrakenteelle... 71

2 4.1 Välisoitto Skeemoilla voi tyyppien kautta tehdä kaikenlaista millä hämätä DTDkadunmiehiä (yhdistely, korvaaminen, abstraktit tyypit; vrt. oliosuunn.) (Myös) skeemojen sisäinen suunnittelu kannattaa kuitenkin tehdä ymmärrettävyyden ja ylläpidon, ei kikkailun näkökulmasta (lue: sitten kun sovelluksen tarpeet ymmärretään ja tekniikan hiominen alkaa...) 72

3 4.2 Kompleksisten tyyppien johtaminen: laajennukset Kompleksinen tyyppi B voidaan laajentaa yksinkertaisen tyypin ohella myös toisesta kompleksisesta tyypistä A (extension) Laajennuksena johdettu kompleksinen tyyppi B on yhdistelmä, jossa - A:n sisältömallin (so. elementtisisältö) perään liitetään B:ssä esitelty sisältömalli - attribuuttien määrittelyt liitetään yhteen Tulos on sama kuin jos A:n määrittely olisi sopivasti kopioitu B:n sisään (elementtisekvenssien yms. merkkausrakenne huomioiden) Asiaa kannattaa miettiä esiintymän näkökulmasta: XML-dokumentissa elementeillä on aina jokin tietty järjestys, attribuuteilla ei ole 73

4 4.3 Esimerkki (1/3): laajennus Tarkastellaan esimerkkiä: halutaan johtaa osoitetyyppi jossa on sekä yleisiä että maakohtaisia osia: <schema targetnamespace=" xmlns=" xmlns:ipo=" <complextype name="address"> <sequence> <element name="name" type="string"/> <element name="street" type="string"/> <element name="city" type="string"/> </sequence> </complextype>... Ts. Address tulee toimimaan kantatyypin tavoin 74

5 4.4 Esimerkki (2/3): laajennus Määritellään uusi tyyppi USAddress laajennuksena: <complextype name="usaddress"> <complexcontent> <extension base="ipo:address"> <sequence> <element name="state" type="ipo:usstate"/> <element name="zip" type="positiveinteger"/> </sequence> </extension> </complexcontent> </complextype> Huomioita: - määrittely perii Address-tyypin elementtirakenteen jonka jälkeen esitellään lisää elementtejä - määrittely ei tuota uutta hierarkiatasoa, vaan sequence-osat yhdistetään implisiittisesti 75

6 4.5 Esimerkki (3/3): laajennus Ja vielä uusi tyyppi UKAddress laajennuksena: <complextype name="ukaddress"> <complexcontent> <extension base="ipo:address"> <sequence> <element name="postcode" type="ipo:ukpostcode"/> </sequence> <attribute name="exportcode" type="positiveinteger" fixed="1"/> </extension> </complexcontent> </complextype> Huomioita: - kuten USAddress, mutta mukana attribuutti - sekä USAdressia että UKAdressia voitaisiin käyttää seuraavien tyyppien perustana ("USAdress_NY") 76

7 4.6 Laajennettujen tyyppien soveltamisesta Laajennuksena johdettua tyyppiä voidaan käyttää kuten se olisi määritelty kopioimalla kantatyypin ja johdetun tyypin määritykset yhteen Tyyppihierarkia mahdollistaa myös olio-ohjelmoinnista tutun käyttötapauksen jossa kantatyypin esiintymä XML-dokumentissa korvataan johdetun tyypin esiintymällä (joskin tämä edellyttää lisämerkkausta XML-dokumenttiin): <?xml version="1.0"?> <ipo:purchaseorder xmlns:xsi=" xmlns:ipo=" orderdate=" "> <!-- elementin shipto tyyppi olisi skeeman mukaan ipo:address : --> <shipto exportcode="1" xsi:type="ipo:ukaddress"> <name>helen Zoe</name> <street>47 Eden Street</street> <city>cambridge</city> <postcode>cb1 1JR</postcode> </shipto>... 77

8 4.7 Kompleksisten tyyppien johtaminen: rajoitteet Kompleksinen tyyppi B voidaan johtaa myös rajoittamalla se olemassa olevasta kompleksisesta tyypistä A (restriction) Johdetun tyypin B mukaiset esiintymät muodostavat osajoukon kantatyypin A mukaisista esiintymistä Rajoitteena johdettu kompleksinen tyyppi on määritys jossa - B esittelee A:n sisältömallin kokonaisuudessaan ("uudestaan"), liittäen määrittelyyn lisää rajoitteita (esim. tarkentamalla kertojia) - attribuutteja ei ole pakko luetella uudelleen, vaan B perii A:n attribuuttimäärittelyt sellaisinaan (ellei toisin sanota) 78

9 4.8 Esimerkki (1/3): rajoitus Tarkastellaan seuraavassa esimerkkiä jossa uusi tyyppi rajoitetaan ao. (kanta)tyypistä PurhaceOrderType:...<complexType name="purchaseordertype"> <sequence> <element name="shipto" type="ipo:address"/> <element name="billto" type="ipo:address"/> <element ref="ipo:comment" minoccurs="0"/> <element name="items" type="ipo:items"/> </sequence> <attribute name="orderdate" type="date"/> </complextype>... Huomioita: - kommentti saa nyt puuttua - attribuutin määrittely Suositus ei sano miten tyypit tulee nimetä (esim. Address, UKAdress), mutta systemaattinen ja järkevä nimikäytäntö toki säästää monelta murheelta 79

10 4.9 Esimerkki (2/3): rajoitus Rajoitettu RestrictedPurchaseOrderType johdetaan pakottamalla tyyppiin kommentti:...<complextype name="restrictedpurchaseordertype"> <complexcontent> <restriction base="ipo:purchaseordertype"> <sequence> <element name="shipto" type="ipo:address"/> <element name="billto" type="ipo:address"/> <element ref="ipo:comment" minoccurs="1"/> <!-- ts. c? c --> <element name="items" type="ipo:items"/> </sequence> </restriction> </complexcontent> </complextype>... Esimerkkejä tyypillistä rajoitteista: - ks. (ja taulukko 3) 80

11 4.10 Tyyppien ja ryhmien uudelleenmäärittely Include ja Import tarjoavat keinon paloitella skeemoja ("kopiointi" ja "sisällyttäminen") skeemastandardi tarjoaa myös näitä vahvemman tavan Uusi vaihtoehto on kierrättää olemassa olevan skeeman A määrittelyjä liittämällä se osaksi skeemaa B siten, että liitoksessa osa A:n sisällöstä määritellään uudelleen (redefine, "päällekirjoittaminen") Tällöin... - ne A:n osat (esim. tyypit) joita ei erikseen uudelleen määritellä kopioituvat B:hen kuten olisi käytetty include-komentoa (*) - uudelleen määritellyt A:n osat vaikuttavat B:n päällekirjoituksen mukaisesti Huom*. Mikäli liitoksessa päällekirjoitetaan A:n osia (esim. kantatyyppi Address) joista A:ssa johdetaan toisia tyyppejä, myös johdetut tyypit muuttuvat automaattisesti siltä osin kun niitäkin ei päällekirjoiteta (esim. UKAdress) 81

12 4.11 Esimerkki (1/2): uudelleen määrittely Esimerkki, "hetkinen... Address-tyypin pitääkin sisältää elementti country" <schema targetnamespace=" xmlns=" xmlns:ipo=" <!-- bring in address constructs --> <redefine schemalocation=" <!-- Address-tyypin uudelleenmäärittely (nyt johtamalla se) --> <complextype name="address"> <complexcontent> <extension base="ipo:address"> <!-- HUOM! ei toimisi muualla --> <sequence> <!-- kuin redefinessä! --> <element name="country" type="string"/> </sequence> </extension> </complexcontent> </complextype> </redefine> <!-- etc. --> </schema> 82

13 4.12 Esimerkki (2/2): esiintymä Kirjoitetaan ipo:ukaddress -tyyppinen esiintymä:... <shipto exportcode="1" xsi:type="ipo:ukaddress"> <name>helen Zoe</name> <street>47 Eden Street</street> <city>cambridge</city> <!-- country was added to Address which is base type of UKAddress --> <country>united Kingdom</country> <!-- postcode was added as part of UKAddress --> <postcode>cb1 1JR</postcode> </shipto>... Huomaa että country vaaditaan nyt siis myös johdetuissa tyypeissä (!) Varovaisuutta vaaditaan, ettei käy niin että (samaan kohdenimiavaruuteen) yritetään määritellä samannimisiä mutta erityyppisiä elementtejä (mikä on virhe) 83

14 4.13 Korvausryhmät Skeema voi määritellä että tietyt sen asettamat (päätason) elementit voidaan korvata toisilla (päätason) elementeillä esiintymässä (substitution group) - (vrt. edellä johdetut tyypit ja xsi:type) Esimerkki: määritellään että XML-dokumentissa saa comment-elementin tilalla esiintyä elementti shipcomment tai elementti customercomment:...<element name="shipcomment" type="string" substitutiongroup="ipo:comment"/> <element name="customercomment" type="string" substitutiongroup="ipo:comment"/>... Esiintymässä näyttää kuin olisi käytetty vaihtoehtoista rakennetta (choice):...<ipo:shipcomment>use gold wrap if possible</ipo:shipcomment>... Huom. skeeman ymmärtäminen vaikeutuu nyt oleellisesti tyypin sallittujen esiintymien selvittämiseksi pitää siis tutkia onko (jossain toisessa kohtaa ko. skeemaa) määritelty vaihtoehtoisia elementtirakenteita (!) 84

15 4.14 Abstraktit määrittelyt (1/3): elementit Elementti tai tyyppi voidaan määritellä myös abstraktina (vrt. oliosuunn.) Abstraktia elementtiä, esim. seuraavaa elementtiä comment... <element name="comment" type="string" abstract="true"/>... ei voi kirjoittaa esiintymään: sen sijaan valitaan elementti vastaavasta korvausryhmästä, esim. <ipo:shipcomment>use gold wrap if possible</ipo:shipcomment> Skeemamäärittelyn näkökulmasta abstrakti (tai muuten vain korvattava) elementti toimii korvausrakenteen tunnisteena -...ts. jota ei yleensä voi skeemassa korvata toiseksi ilman että skeeman merkitys muuttuisi 85

16 4.15 Abstraktit määrittelyt (2/3): tyypit Skeemassa voidaan määritellä myös abstrakteja tyyppejä Esimerkki, määritellään abstrakti kulkuneuvon käsite, tyyppi Vehicle: <schema xmlns=" targetnamespace=" xmlns:target=" <complextype name="vehicle" abstract="true"/> <complextype name="car"> <complexcontent> <extension base="target:vehicle"/> </complexcontent> </complextype> <complextype name="plane"> <complexcontent> <extension base="target:vehicle"/> </complexcontent> </complextype>... </schema> 86

17 4.16 Abstraktit määrittelyt (3/3): esimerkki tyypeistä Määritellään sitten kaksi elementtiä transport ja sedan: <element name="sedan" type="target:car"/> <!-- tyyppi konkreettinen --> <element name="transport" type="target:vehicle"/> <!--tyyppi abstr. --> Nyt kumpikaan elementeistä ei ole abstrakti, niinpä ne voivat esiintyä skeeman mukaisessa XML-dokumentissa, esim. <sedan/> Mutta: koska elementin transport tyyppi on abstrakti (Vehicle), pitää tämän esiintymässä valita jokin johdettu (konkreettinen) tyyppi, esim. <transport xmlns=" xmlns:xsi=" xsi:type="car"/> Ts. abstrakti määrittely (elementti tai tyyppi) ei sellaisenaan koskaan päädy esiintymään asti 87

18 4.17 Tyyppien johtamisen rajoittaminen (1/3): final Tyyppien johtaminen voidaan myös kieltää antamalla määre final joka voi saada arvot: - restriction: tyypistä ei saa rajoittaa uutta tyyppiä - extension: tyypistä ei saa laajentaa uutta tyyppiä - #all: minkäänlainen johtaminen ei ole sallittua Esim. "Address-tyypistä ei saa johtaa tyyppejä rajoittamalla" <complextype name="address" final="restriction"> <sequence> <element name="name" type="string"/>... </sequence> </complextype> Skeeman kaikki tyyppimäärittelyt voidaan pakottaa final-määreen tavoin antamalla schema-elementissä attribuutti finaldefault="restriction" (jne.) 88

19 4.18 Tyyppien johtamisen rajoittaminen (2/3): fasetit Yksinkertaisten tyyppien tapauksessa voidaan myös yksitellen luetella minkä fasettien muuttaminen ei ole johdetuissa tyypeissä sallittua: <simpletype name="postcode"> <restriction base="string"> <length value="7" fixed="true"/> </restriction> </simpletype> Tyyppiä voidaan edelleen rajoittaa, esim. <simpletype name="ukpostcode"> <restriction base="ipo:postcode"> <pattern value="[a-z]{2}\d\s\d[a-z]{2}"/> </restriction> </simpletype>...muttei fasetin length osalta 89

20 4.19 Tyyppien johtamisen rajoittaminen (3/3): korvaaminen On myös mahdollista rajoittaa korvausryhmien ja johdettujen tyyppien mukaisten vaihtoehtoisten elementtien käyttöä esiintymässä Esimerkki: - oletetaan että tyyppi B on rajoittamalla johdettu tyypistä Address - nyt halutaan kieltää että esiintymään voidaan Address-tyyppisen elementin paikalle kirjoittaa B-tyyppinen elementti <complextype name="address" block="restriction"> <sequence> <element name="name" type="string"/>... </sequence> <!-- Address voidaan kuitenkin nyt korvata --> </complextype> <!-- laajennetun tyyppisellä elementillä --> Kuten final, block voi saada myös arvot extension ja #all, ja schemaelementissä voidaan antaa attribuutti blockdefault="restriction" (jne.) 90

21 4.20 Esiintymän yksikäsitteisyys DTD määritteli ID-tyyppisen attribuutin joka tuli olla arvoltaan yksikäsitteinen Skeemat vievät ajatuksen pidemmälle tarjoamalla mahdollisuuden vaatia että minkä tahansa elementin tai attribuutin arvo on yksikäsitteinen tietyn esiintymän tietorakenteen sisällä XPath-viittausten avulla Esimerkki: Vaaditaan että esiintymän items-elementin lapset item voidaan yksilöidä osanumeron (partnum) ja tuotenimen (productname) perusteella <xsd:element name="items" type="items">... <xsd:unique name="partnumandname"> <xsd:selector xpath="item"/> <xsd:field <xsd:field xpath="productname"/> </xsd:unique> </xsd:element> selector valitsee vaatimuksen alan (scope), ja field-elementit luettelevat yksilöivät rakenteet suhteessa tähän (nyt attribuutti ja lapsielementti) 91

22 4.21 Avaimet ja viittaukset: Esimerkki (1/3) Eheiden viittausten varmistamiseen tarvitaan ID/IDREF:n kaltainen pari Esimerkki, tavaratoimituksia tietyille alueille: <purchasereport date=" " xmlns:xsi=" xsi:nonamespaceschemalocation="report.xsd"> <regions> <region areacode="03">tampere</region> <region areacode="09">helsinki</region> <region areacode="02">turku</region> </regions> <parts> <part destination="03">ruohonleikkuri</part> <part destination="03">kuokka</part> <part destination="09">kottikärryt</part> </parts> </purchasereport> 92

23 Avaimet ja viittaukset: Esimerkki (2/3) Skeema määrittelee asian key/keyref-esittelyillä; ensin vaaditaan että osa tyypin esiintymästä toimii yksikäsitteisenä avaimena:...<xsd:element name="purchasereport"> <xsd:complextype> <xsd:sequence> <xsd:element name="regions" type="regionstype"/> <xsd:element name="parts" type="partstype"/> </xsd:sequence> <xsd:attribute name="date" type="xsd:date"/> </xsd:complextype>... <xsd:key name="akey"> <xsd:selector xpath="regions/region"/> <xsd:field <!--aluenumero on avain--> </xsd:key> 93

24 4.22 Avaimet ja viittaukset: Esimerkki (3/3)...sitten sanotaan minkä osan esiintymää on viitattava ko. avaimeen (refer):... <xsd:keyref name="dummy2" refer="akey"> <xsd:selector xpath="parts/part"/> <xsd:field <!-- viittaus avaimeen --> </xsd:keyref> </element>... Määritys pakottaa että viittaukset osuvat aina avaimiin (akey) 1:1-viittausrakennetta ei oletuksena vaadita, ts. kaikkiin avaimiin ei ole pakko viitata ja yhteen avaimeen voidaan viitata monta kertaa (tämäkin voidaan toki pakottaa, vrt. unique) Avainten ja viittausten syntaksi on vastaava unique-määrittelyn kanssa; ne voidaan siis erityisesti rakentaa myös useista (eritasoisista!) field-osista XPath-lausekkeet ovat XML-skeemoissa muodoltaan rajoitettuja 94

25 4.23 Lopuksi XML-skeeman avulla voi siis: - validoida esiintymän skeeman suhteen, ja - tuoda lisätietoja esiintymän tulkintaan (ns. infoset contributions) XML Schema ei yleisnimestään huolimatta ole vahvin/yleisin ajateltavissa oleva skeemakieli (vrt. hahmopohjainen Schematron) - skeemassa ei esim. pystytä sanomaan näin: "Jos esiintymässä on annettu attribuutti address/@country='fi', lapsielementin address/phone arvo pitää alkaa koodilla '+358'." (mieti!) Tässä tyydymme toteamaan että muita tunnettuja skeemakieliä ovat esim. Relax NG ja (erityisesti) ISO-standardoitu ISO Schematron - ks. ja 95