10 XML ja dokumenttien tyyppimäärittely

Transkriptio

1 10 XML ja dokumenttien tyyppimäärittely XML tarjoaa perussyntaksin dokumenttien mielivaltaista merkkaamista varten Huomionarvoista: - merkkidatan ja merkkauksen koodauksen valinta (sama kaikille XMLdokumenteille) - dokumentin loogisen rakenteen kuvaaminen omien elementtirakenteiden avulla (XML-suunnittelijan valinnan mukaan XML-syntaksin puitteissa) Kuten jo aikaisemmin todettiin, XML-kielioppi määrittää XML-dokumenttien luokan (=kaikki XML-kieliopin mukaiset tekstidokumentit) Käytännön sovelluksissa on kuitenkin tarkoituksenmukaista jakaa XMLdokumenttien luokka pienempiin osiin, aliluokkiin, esim. tyyliin: - kakkureseptit - novellit - kirjeet RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 181

2 Kukin aliluokkia edustavista dokumenteista on edelleen XML-syntaksin mukainen XML-dokumentti, jonka looginen rakenne on ko. aliluokalle tunnusomainen - kakkuresepteihin liitetään yleensä kakun nimi, valmistusaineet, leipomisohje sekä paistoaika - novelleihin liitetään yleensä kertomuksen nimi, kirjoittaja, esipuhe, kääntäjän huomautuksia sekä varsinainen tarina luvuiksi ja kappaleiksi jaoteltuna - kirjeessä on yleensä lähettäjän ja vastaanottajan nimi ja osoite, päivämäärä sekä vapaamuotoista sisältötekstiä Dokumenttiluokan dokumenttien looginen rakenne voi yleensä myös hieman vaihdella ilman että dokumenttiluokka muuttuu miksikään (esim. kirjeessä ei välttämättä ole lähettäjän osoitetta) - tällöin voidaan puhua geneerisistä dokumenttiluokista Huomaa, että dokumenttiluokat eivät (välttämättä) ole toisensa poissulkevia (esim. runon ja pienen novellin (geneerinen) looginen rakenne saattaa hyvinkin olla sama) RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 182

3 Dokumenttien jako aliluokkiin tehdään yleensä niiden loogisen elementtirakenteen pohjalta käytännöllisistä syistä - dokumenttien luokittelu ei kuitenkaan välttämättä heijastele niiden asiasisältöä (vaikka tähän tietenkin pyritään) Elävässä elämässä dokumenttiluokat määräytyvät yleensä vallitsevan käytännön mukaisesti ilman formalisoituja dokumenttien luokkamäärityksiä - yritäpä etsiä jostain täsmällinen ohje kirjeen kirjoittamiseen! - toki joissain tapauksissa tavanomaisten dokumenttiluokkien kuvailuun on olemassa mallipohjia (esim. lomakkeet tai yrityskirjeiden mallit) Periaatteessa tämä riittäisi myös XML-dokumenttien tapauksessa - voimmehan aina sopia (esim. suullisesti tai esimerkkien muodossa) minkä nimisiä elementtejä valitun dokumenttiluokan dokumentit sisältävät ja mitkä ovat elementtien yhdistelyyn käytettävät säännöt Edut - dokumenttien kirjoittaminen ilman turhaa miettimistä RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 183

4 Haitat - dokumenttiluokista tulee epämääräisiä - mikä hankaloittaa osaltaan halutunlaisten dokumenttien kirjoittamista ja lukemista - XML on suunniteltu täsmälliseksi tavaksi esittää dokumentteja - miksi moinen vaiva, jos sisältö on mitä tahansa Käytännössä XML:ssä dokumenttiluokat ilmaistaan XML-syntaksin mukaisen täsmällisen dokumentin tyyppimäärityksen muodossa ([document type definition]) (vrt. XML-kielen syntaksin esittäminen EBNF-muotoisena XMLkielioppina) - tyyppimääritys esittelee elementtien nimet, merkinnät ja dokumentin loogisen rakenteen tuottosäännöt dokumentin tyyppimääritys merkataan dokumenttiin dokumentin tyyppijulistuksen ([document type declaration]) avulla, joka formalisoi intuitiivisen dokumenttiluokan määrittämisen idean: tyyppijulistus kertoo minkätyyppisestä dokumentista on kyse RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 184

5 Tyyppijulistuksen syntaksi Dokumentin tyyppijulistus voi koostuu seuraavista erityyppisistä merkkausjulistuksista ([markup deklaration]) seuraavasti: - notaatiojulistus ([notation declaration]) - elementin tyyppijulistus ([element type declaration]) - attribuuttilistan julistus ([attribute-list declaration]) - entiteettijulistus ([entity declaration]) Dokumentin tyyppijulistus liitetään aina XML-dokumentin esittelyosaan: [22] prolog ::= XMLDecl? Misc* (doctypedecl Misc*)? Tyyppijulistus käyttää DOCTYPE-avainsanaa (vrt. HTML:n tyyppimäärittely aikaisemmin): [28] doctypedecl ::= '<!DOCTYPE' S Name (S ExternalID)? S? ('[' intsubset ']' S?)? '>' [VC: Root Element Type] [WFC: External Subset] RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 185

6 Elementti- attribuutti- entiteetti- ja notaatiojulistusten ohella tyyppijulistukseen voi sisällyttää myös prosessointiohjeita ja kommentteja: [29] markupdecl ::= elementdecl AttlistDecl EntityDecl NotationDecl PI Comment [ VC: Proper Declaration/PE Nesting ] [ WFC: PEs in Internal Subset ] Ulkoisen DTD-viittauksen avulla dokumentin tyyppimääritys voidaan kirjoittaa myös tekstitiedostoon, johon viitataan XML-dokumentin tyyppijulistuksessa: [75] ExternalID ::= 'SYSTEM' S SystemLiteral 'PUBLIC' S PubidLiteral S SystemLiteral Käytännössä tämä tarkoittaa sitä, että dokumentin tyyppimääritys jakautuu kahteen osaan, jotka yhdessä muodostavat dokumentin tyyppimäärityksen: - sisänen DTD-osajoukko ([internal DTD-subset]) ja ulkoinen DTDosajoukko ([external DTD-subset]) Jos sekä sisäinen että ulkoinen DTD-osajoukko ovat käytössä, merkkausjulistukset yhdistetään ja sisäisen DTD-osajoukon esittelevät entiteetti- ja attribuuttilistajulistukset korvaavat ulkoisen osajoukon esittelevät (elementtijulistusten päällekirjoittaminen ei ole mahdollista) RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 186

7 Esimerkki: XML-dokumentti, jolla tyyppimääritys Seuraava XML-dokumentti sisältää yksinkertaisen dokumentin tyyppimäärityksen: Tiedosto entiteetit.ent: <!ENTITY signature "-= tieto lisää tuskaa =-"> Tiedosto dokumentti.xml: <?xml version="1.0"?> <!DOCTYPE mydoc SYSTEM "entiteetit.ent" [ <!ELEMENT mydoc (title, body)> <!ELEMENT title (#PCDATA)> <!ELEMENT body (#PCDATA)> ]> <mydoc> <title>validi XML-dokumentti</title> <body> Hei maailma! <&signature;> </body> </mydoc> RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 187

8 Huomioita: - tiedosto dokumentti.xml on (hyvin muodostettu) XML-dokumentti - tiedosto entiteetit.dtd on pelkkä tekstitiedosto (tiedostopäätteeksi valitaan yleensä jokin seuraavista: dtd, ent, txt) - XML-dokumentin dokumentti.xml elementtirakenne noudattaa DTD:ssä esitettyä (elementtien määrittelyyn palataan pian) - kyseessä on ns. validi XML-dokumentti - kyseisen dokumentin DTD koostuu sekä sisäisestä että ulkoisesta DTDosajoukosta (kumpikaan yksinään ei riitä) - XML-dokumentin esittelyosa sisältää nyt dokumentin tyyppijulistuksen - XML-dokumentin esiintymä muuten kuten (hyvin muodostetussa) XMLdokumentissa, mutta kyseinen dokumentti ei voi olla hyvin muodostettu (eikä siis XML-dokumentti) ilman tyyppijulistusta (entiteetti signature pitää esitellä) XML-dokumentin yhteydessä voidaan käyttää myös pelkästään sisäistä tai ulkoista DTD-osajoukkoa (valinta tehdään käytännöllisistä syistä) RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 188

9 Koko DTD voidaan esitellä myös sisäisen DTD-osajoukon avulla. <?xml version="1.0"?> <!DOCTYPE mydoc [ <!ELEMENT mydoc (title, body)> <!ELEMENT title (#PCDATA)> <!ELEMENT body (#PCDATA)> ]> <mydoc><title>xml-dokumentti</title><body>hei vaan!</body></mydoc> Vastaavasti DTD voidaan sijoittaa kokonaisuudessaan erilliseen tiedostoon (ulkoinen DTD-osajoukko) tyyliin (huomaa avainsana SYSTEM): <?xml version="1.0"?> <!DOCTYPE mydoc SYSTEM "dokumenttityyppi.dtd"> <mydoc><title>xml-dokumentti</title><body>hei vaan!</body></mydoc> Tällöin tekstitiedosto (dokumenttityyppi.dtd) sisältää rivit: <!ELEMENT mydoc (title, body)> <!ELEMENT title (#PCDATA)> <!ELEMENT body (#PCDATA)> Avainsana SYSTEM voidaan korvata myös sanalla PUBLIC - ero on lähinnä siinä, että PUBLIC DTD:t ovat (prosessorin) näkökulmasta yleisesti tunnettuja RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 189

10 DTD-osajoukkojen avulla dokumenttiluokkien käsittely tehostuu: - ulkoinen DTD-osajoukko mahdollistaa yhden ja saman merkkausjulistuksia sisältävän tiedoston käyttämisen usean XMLdokumentin tyyppijulistuksessa (käytännössä URL-viittauksella) - sisäisen DTD-osajoukon avulla on usein kätevää suunnitella merkkausjulistuksia ja toisaalta täsmentää dokumentin tyyppimääritystä (esim. entiteettien ja attribuuttien osalta) Kaikkia mahdollisia merkkausjulistuksia ei välttämättä ole mahdollista jakaa eri DTD-osajoukkoihin (lähinnä tietyntyyppisiä entiteettejä) Lopuksi on jälleen kerran syytä todeta, että XML sisältää useita eritasoisia syntaktisia määrityksiä: - dokumentin merkkikoodaus: Unicode - dokumentin syntaksi: XML-kielioppi ja rajoitteet - dokumentin esiintymän looginen rakenne: DTD-kielioppi - DTD-kieliopin rakenne: suunnitellaan sovelluksen mukaan RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 190

11 Elementin tyyppijulistus Kuten tunnettua, XML-dokumenttien loogisen rakenteen peruspalasia ovat elementit, esim: <example>hei vaan!</example> Elementtien syntaksi seuraa suoraan XML-spesifikaation kieliopista; looginen elementtirakenne sen sijaan voi syntaksin puitteissa vaihdella paljonkin, siis esimerkiksi: <doc> <elem>hei</elem> <elem>vaan</elem> </doc> on eri asia kuin: <doc> <elem> <elem>hei vaan</elem> </elem> </doc> RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 191

12 Dokumentin tyyppimäärityksessä on mahdollista täsmällisesti määrätä, minkälaisia rakenteita (ko. tyyppisten dokumenttien) elementeistä saa muodostaa Konkreettisesti määritys suoritetaan dokumentin tyyppijulistukseen sisällytettävän elementin tyyppijulistuksen avulla: [45] elementdecl ::= '<!ELEMENT' S Name S contentspec S? '>' [ VC: Unique Element Type Declaration ] Elementin mahdollinen sisältö luokitellaan seuraavasti: [46] contentspec ::= 'EMPTY' 'ANY' Mixed children Näiden merkitys on kutakuinkin seuraava: - EMPTY ~ tyhjä elementti - ANY ~ mitä tahansa sisältöä (käytetään yleensä vain kehitysvaiheessa) - Mixed content ~ elementin sisältö yhdistelmä merkkidataa ja lapsielementtejä - Element content ~ elementin sisältönä ainoastaan elementtejä XML:ssä elementtien jaottelu näiden (tieto)tyyppien mukaan on suurpiirteistä RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 192

13 Ohessa esimerkkejä elementtien tyyppijulistuksista ja otteita niitä vastaavista XML-dokumenteista (huomaa EBNF-tyyppiset operaattorit ja kertojat): (1) <!ELEMENT example EMPTY>... <example/> (2) <!ELEMENT example ANY>... <example>hei maailma!<example/></example> (3) <!ELEMENT example (#PCDATA code field)*> <!ELEMENT code (#PCDATA)*> <!ELEMENT field (#PCDATA)*>... <example>hei maailma <field>hej</field> Hi <code>moi</code> Hello </example> (4) <!ELEMENT example (code field?)> <!ELEMENT code (#PCDATA)*> <!ELEMENT field (#PCDATA)*>... <example> <field>hej</field> </example> RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 193

14 Sisältönä tekstiä ja elementtejä: mixed content Mixed-content -tyypissä elementin sisällä saa olla merkkidataa ja lapsina erikseen nimettyjä elementtejä mielivaltaisessa järjestyksessä. Vastaava XMLtuottosääntö on seuraava: [51] Mixed ::= '(' S? '#PCDATA' (S? ' ' S? Name)* S? ')*' '(' S? '#PCDATA' S? ')' [ VC: Proper Group/PE Nesting ] [ VC: No Duplicate Types ] Esimerkkejä: <!ELEMENT example (#PCDATA H1 H2 H3)*> <!ELEMENT field (#PCDATA a b)*> <!ELEMENT field (#PCDATA field a b)*> <!ELEMENT code (#PCDATA)> Tunniste #PCDATA tarkoittaa jäsennettyä merkkidataa (~saa sisältää entiteettejä, merkkiviittauksia, jne.), muut elementtien (tyyppien) nimiä Elementin lapsielementtien järjestystä ei voi valita, kuten ei merkkidatan kirjoituskohtaakaan RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 194

15 Huomioita mixed content -elementtimäärittelystä: - alkaa aina kentällä #PCDATA - operaattorina aina OR (" ") XML ja dokumenttien tyyppimäärittely - mikäli sisältää viittauksia elementtien (tyyppien) nimiin, päättyy aina kertojaan "*" "Mixed" -termin käyttö on paikoitellen hieman harhaanjohtavaa; elementin sisällöksi voidaan pakottaa pelkkää tekstiä (ts. ei lapsielementtejä): <!ELEMENT code (#PCDATA)> Element content -vaihtoehdossa elementin sisällä saa olla ainoastaan elementtejä, mutta dokumentin looginen rakenne on yksityiskohtaisemmin määritettävissä. Vastaavat XML-tuottosäännöt ovat: [47] children ::= (choice seq) ('?' '*' '+')? [48] cp ::= (Name choice seq) ('?' '*' '+')? [49] choice ::= '(' S? cp ( S? ' ' S? cp )+ S? ')' [ VC: Proper Group/PE Nesting ] [50] seq ::= '(' S? cp ( S? ',' S? cp )* S? ')' [ VC: Proper Group/PE Nesting ] RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 195

16 Sisältönä elementtejä: element content Kun elementin sisältö määritellään element content -tyyppiseksi, voidaan lapsielementtien rakenne määrittää monipuolisesti EBNF:stä tuttujen operaattoreiden ja kertojien avulla (kyseessä on kuitenkin eri syntaksi) Esimerkki: <!ELEMENT mydoc (title?,code+,(footer comment)?)> XML-DTD tunnistaa seuraavat operaatorit: - A,B (B seuraa A:ta) - A B (A tai B) ja seuraavat kertojat: - A? (A on optionaalinen) - A+ (A esiintyy yhden tai useamman kerran) - A* (A esiintyy yhden tai useamman kerran tai ei ollenkaan) Lausekkeiden ryhmittelyyn käytetään tavallisia sulkuja ("(",")") RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 196

17 Tarkista tyhjämerkkien ja sulkujen kirjoitussäännöt spesifikaation tuottosäännöistä! Yhdistelemällä elementtien nimiä sopivasti operaattoreita, kertojia ja sulkuja käyttämällä, voidaan määrittää elementin sisältömalli ([content model]) Sisältömalleja on usein tarkoituksenmukaista jakaa pienempiin osiin sääntöjen lukemisen ja kirjoittamisen helpottamiseksi (huomaa ero merkkauksessa!): <!ELEMENT mydoc (title?,code+,misc)> <!ELEMENT misc ((footer comment)?)> Mikäli ylimääräisiä elementtejä (yllä misc-elementti) ei dokumentteihin haluta, voidaan elementtien tyyppijulistuksia sieventää ns. parametrientiteettien avulla (näihin palataan myöhemmin) Elementtien sisältömallit voivat olla varsin mutkikkaita sisältäen myös rekursiivisia (itseensä viittaavia) rakenteita (rekursioonkin palataan vielä) Yhden ja saman (ei-triviaalin) loogisen elementtirakenteen voi yleensä ilmoittaa useilla eri elementin tyyppijulistuksella Elementin tyyppijulistusten on oltava yksikäsitteisiä, ts. tyyppijulistusten päällekirjoittaminen tai epädeterministisinä tuottosääntöinä tulkitseminen ei ole sallittua (mikä on harmi!) RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 197

18 Attribuuttilistan julistus Attribuutit ovat (yleensä) elementteihin liittyviä lisämääreitä, esim. tyyliin: <example color="red" shape="circle">hei maailma!</example> Attribuuttien syntaksi seuraa suoraan XML-spesifikaation kieliopista; sen sijaan elementtiin liitettävien attribuuttien nimet, arvojoukot ja attribuuttien (pakollinen) esiintyminen elementeissä voivat syntaksin puitteissa vaihdella paljonkin, siis esimerkiksi (tarkkaan ottaen): <example color="red" shape="circle"/> on sama asia kuin: <example shape="circle" color="red"/> mutta saattaa olla (loogisesti) eri asia kuin: <example color="red"/> RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 198

19 On syytä huomata, että vaikka elementtien tekstisisällön tarkka määrittely ei XML:ssä onnistu, on attribuuttien arvojen tyypittäminen mahdollista (tosin vain ylimalkaisesti) Attribuutit määritellään aina tietyntyyppisille (tietynnimisille) elementeille, määrittely suoritetaan (elementin) attribuuttilistan julistuksen avulla, esim. tyyliin: <!ELEMENT example EMPTY> <!ATTLIST example color (red green blue) "red"> Koska julistukseen kirjoitetaan aina sen elementin nimi, johon attribuutiti voidaan liittää, ovat erityyppisille elementeille esiteltävät samannimiset attribuutit eri attribuutteja, vrt: <!ELEMENT example EMPTY> <!ELEMENT code (#PCDATA)> <!ATTLIST example color (red green blue) "red"> <!ATTLIST code color CDATA "red"> Attribuuttilistan julistus annetaan XML-kieliopissa muodossa: [52] AttlistDecl ::= '<!ATTLIST' S Name AttDef* S? '>' [53] AttDef ::= S Name S AttType S DefaultDecl RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 199

20 Kuten edellisistä esimerkeistäkin käy ilmi, attribuuttijulistusten yhteydessä esiintyy yleensä myös avainsanoja tai oletusarvoja (ns. attribuutin oletusmääritykset ([default declaration])). Näiden merkitys on seuraava: - #REQUIRED ~ attribuutin arvo on pakko antaa - #IMPLIED ~ attribuutin antaminen on vapaaehtoista - #FIXED ~ attribuutin arvo on vakio - attribuuteille voidaan lisäksi määritellä arvojoukkoja ja oletusarvoja Attribuuttien oletusmääritykset on XML-kieliopissa määritelty seuraavasti: [60] DefaultDecl ::= '#REQUIRED' '#IMPLIED' (('#FIXED' S)? AttValue) [ VC: Required Attribute ] [ VC: Attribute Default Legal ] [ WFC: No < in Attribute Values ] [ VC: Fixed Attribute Default ] RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 200

21 Attribuutin (oletus)arvo on merkkidataa ja voi sisältää entiteetti- tai merkkiviittauksia: [10] AttValue ::= '"' ([^<&"] Reference)* '"' "'" ([^<&'] Reference)* "'" Esimerkkejä (eri julistuksista): <!ATTLIST example color (red green blue) #REQUIRED> <!ATTLIST example color CDATA #REQUIRED> <!ATTLIST example color (red green blue) "red"> <!ATTLIST example color CDATA #IMPLIED> <!ATTLIST example color CDATA #FIXED "red"> Yleensä oletusmäärityksinä käytetään literaalina annettavia oletusarvoja tai vaatimusta attribuutin antamisesta Muillekin löytyy toki käyttöä: - IMPLIED-attribuutti sopii esimerkiksi vapaaehtoisesti sovellukseen syötettävien tietojen esittämiseen - FIXED-attribuutin avulla voidaan kiinnittää tietoa johonkin sovelluskohtaiseen muotoon, esimerkiksi kiinnittää xml:lang attribuutin arvoksi "fi" RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 201

22 Attribuuttien tyypit XML-syntaksin näkökulmasta attribuuttien arvot ovat aina merkkijonoja tai merkkidataa, joka saattaa sisältää entiteetti- tai merkkiviittauksia XML:n puitteissa attribuuttien arvojen täsmällisempi (rajaavampi) tyypittäminen on kuitenkin mahdollista - käytännössä tämä tarkoittaa sitä, että kaikentyyppinen merkkidata ei (aina) attribuutin arvoksi kelpaa Aikaisemmissa esimerkeissä attribuutin tyyppeinä oli yksinkertaisesti joko merkkidata tai lueteltuja arvojoukkoja, tyyliin: <!ATTLIST example color (red green blue) #REQUIRED> <!ATTLIST example color CDATA #REQUIRED> Käytännössä tämä riittää yleensä mainiosti. XML-prosessori/sovellus - asetelman puitteissa on kuitenkin tilanteita, joissa arvojoukkojen yksityiskohtaisempi määrittäminen on perusteltua, esim. kun - attribuutit viittaavat nimettyihin XML-elementteihin - tiedetään, että sovellus aikoo käyttää (joidenkin) attribuuttien arvoja esim. tiedostoniminä RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 202

23 Perusideana on siis attribuuttien (syntaktisen) rakenteen (oikeellisuuden) tutkiminen jo XML-prosessorin avulla niin pitkälle kuin mahdollista (tai pikemminkin käytännöllistä) XML:ssä attribuuttien tyypit (arvojoukot) voivat olla jotakin seuraavista: - CDATA ~ merkkidataa - lueteltu (enumerated) ~ jokin annetuista tunnistemerkkijonoista - NOTATION ~ jokin annetuista notaatioista - ID ~ ID-attribuutti - IDREF ~ viittaus ID-attribuuttiin - IDREFS ~ luettelo viittauksista ID-attribuutteihin (erottimena tyhjämerkki) - ENTITY ~ entiteetin nimi - ENTITIES ~ luettelo entiteettien nimiä (erottimena tyhjämerkki) - NMTOKEN ~ tunnistemerkkijono - NMTOKENS ~ luettelo tunnistemerkkijonoja (erottimena tyhjämerkki) RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 203

24 On tärkeää huomata, että XML-dokumenttissa näkyvään elementtiin kirjoitettu attribuutin arvo käy aina läpi normalisointiprosessin matkallaan XMLprosessorin läpi kohti sovellusta (tähän palataan pian) Attribuuttien tyypit on XML-kieliopissa määritelty seuraavasti (tuottosäännön 56 rajoitteet on alla kirjoitettu lyhyempään muotoon: [54] AttType ::= StringType TokenizedType EnumeratedType [55] StringType ::= 'CDATA' [56] TokenizedType ::= 'ID' 'IDREF' 'IDREFS' 'ENTITY' 'ENTITIES' 'NMTOKEN' 'NMTOKENS' [ VC: ID ] [ VC: One ID per Element Type ] [ VC: ID Attribute Default ] [ VC: IDREF ] [ VC: Entity Name ] [ VC: Name Token ] Nimen mukaisesti attribuuttilistat määritellään elementeille kerralla esim. tyyliin: <!ELEMENT example EMPTY> <!ATTLIST example id ID #REQUIRED file NMTOKEN #IMPLIED> RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 204

25 Attribuuttijulistusten yhdistäminen vs. hajauttaminen Toisin kuin elementtien tyyppijulistukset, jotka aina pitää antaa kerralla, attribuuttijulistukset voidaan antaa myös osissa: Siis esimerkiksi: <!ELEMENT example EMPTY> <!ATTLIST example color CDATA #REQUIRED> <!ATTLIST example shape (box circle line) "box"> voidaan esittää myös yhtäpitävästi listamuodossa <!ELEMENT example EMPTY> <!ATTLIST example color CDATA #REQUIRED shape (box circle line) "box"> Erityisen kätevää tämä on DTD:n hajauttamisen näkökulmasta, sillä näin ulkoisessa DTD-osajoukossa esitetyille elementeille voidaan antaa jälkikäteen uusia attribuutteja sisäisessä DTD-osajoukossa Attribuuttijulistusten päällekirjoittaminen ei kuitenkaan ole mahdollista (monikertaisista attribuuttijulistuksista merkitsevä on aina ensimmäinen) RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 205

26 Attribuuttien arvojen normalisointi Attribuuttien arvot ovat jäsennettäväksi tarkoitettua tekstiä, tämä tarkoittaa käytännössä sitä, että XML-prosessorin sovellukselle välittämä merkkijono ei välttämättä ole täsmälleen sama kuin dokumenttiin kirjoitettu literaaliarvo Attribuuttien arvo määräytyy aina ns. normalisointiprosessin perusteella, jossa literaalista prosessoidaan (XML-)sovellukselle välitettävä attribuuttiarvo Attribuuttien arvojen normalisointialgoritmi on seuraavanlainen: 1) arvon ympäriltä poistetaan lainausmerkit (tai heittomerkit) 2) merkkiviittaukset korvataan vastaavilla Unicode-merkeillä 3) entiteettiviittaukset korvataan vastaavilla merkkijonoilla (mahdollisesti rekursiivisesti) 4) kaikki tyhjämerkit (siis myös rivinvaihdot, [newline]) korvataan välilyönneillä #x20 (poikkeus entiteeteille #xd#xa::=#x20) 5) jos attribuutin tyyppi on jokin muu kuin CDATA, poistetaan välilyönnit merkkijonon alusta ja lopusta sekä moninkertaiset välilyönnit merkkijonon sisältä RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 206

27 Normalisoinnin ansiosta myös attribuuttien arvojen antamisen yhteydessä voi käyttää tyhjämerkkejä ja vaikkapa jakaa arvo usealle riville tyyliin: <!ATTLIST desc text CDATA #REQUIRED>... <desc text="tämä rivi tekstiä on Ö-luokan esimerkki. "> Edellisessä esimerkissä attribuutin text (jonka tyypiksi on annettu CDATA) arvo normalisoidaan muotoon (hakasulut on esimerkissä lisätty ainoastaan havainnollistamaan merkkijonon alku- ja loppukohtia) [Tämä rivi tekstiä on Ö-luokan esimerkki. ] Huomaa, että normalisaatio tuottaa erilaisen arvon, jos attribuutin tyypiksi olisi annettu esim. NMTOKENS muodossa: <!ATTLIST desc text NMTOKENTS #REQUIRED>... <desc text="tämä rivi tekstiä on Ö-luokan esimerkki. "> tällöin arvo normalisoitaisiin muotoon: [Tämä rivi tekstiä on Ö-luokan esimerkki.] RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 207

28 Attribuuttityyppien esittely Yksinkertaisin attribuuttityyppi on CDATA ([character data]), joka sisältää jäsennettävää merkkidataa - rakenteeton attribuuttiarvo - tyhjämerkkien normalisointi: vain rivinvaihdot ja alku- ja loppuvälilyönnit - myös tyhjä arvo "" kelpaa Esimerkki: <!ATTLIST example text CDATA #REQUIRED>... <example text="ainoastaan < ja &-merkit on koodattava entiteeteillä, #$@!""/> NMTOKEN-tyyppinen ([name token], tunnistemerkkijono) attribuutti hyväksyy arvokseen tunnistemerkkijonon (Nmtoken-tuottosääntö) - arvona vain tunnistemerkkijonoon kelpaavia merkkejä (sekä mahdollisesti tyhjämerkkejä alussa ja lopussa) RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 208

29 - tyhjämerkkien normalisointi koko komeudessaan - tyhjä arvo "" ei kelpaa Esimerkki: <!ATTLIST example indexpage NMTOKEN #REQUIRED> <example indexpage="etusivu.html"/> XML ja dokumenttien tyyppimäärittely NMTOKENS-tyyppinen attribuutti hyväksyy arvokseen luettelon tunnistemerkkijonoja (muuten kuten NMTOKEN) - arvona vain tyhjämerkeillä erotettuja tunnistemerkkijonoja - tyhjämerkkien normalisointi koko komeudessaan - tyhjä arvo "" ei kelpaa Esimerkki: <!ATTLIST example pet NMTOKENS #REQUIRED>... <example pet="kissa koira marsu härkä muu"/> RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 209

30 Lueteltu attribuutti (enumerated) hyväksyy arvokseen jonkin luetelluista tunnistemerkkijonoista - arvo täsmälleen jokin luetelluista - tyhjämerkkien normalisointi: vain rivinvaihdot ja alku- ja loppuvälilyönnit Esimerkki: <!ATTLIST example shape (box circle line) "">... <example shape="box"/> NOTATION-tyyppinen attribuutti on muuten kuten lueteltu attribuutti, mutta lueteltujen tunnistemerkkijonojen pitää olla esiteltyjä XML-notaatioita (tähän palataan pian) ID--tyyppinen attribuutti hyväksyy arvokseen (ko. XML-dokumentissa) ainutkertaisen nimi-tyyppisen merkkijonon (Name-tuottosääntö) - tyhjämerkkien normalisointi: vain rivinvaihdot ja alku- ja loppuvälilyönnit - tyhjä arvo "" ei kelpaa - elementillä voi olla korkeintaan yksi ID-tyyppinen attribuutti RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 210

31 - ID-tyyppisen attiribuutin nimeen liitetään usein merkkijono "id" selkeyttämään attribuutin merkitystä Esimerkki: <!ATTLIST example id ID #REQUIRED>... <example id="id-ja-idref-attribuutti"/> IDREF--tyyppinen attribuutti hyväksyy arvokseen jonkin (ko. XMLdokumentissa) ID-tyyppisen attribuutin arvon - tyhjämerkkien normalisointi: vain rivinvaihdot ja alku- ja loppuvälilyönnit - tyhjä arvo "" ei kelpaa - IDREF-tyyppisen attribuutin nimeen liitetään usein esim. merkkijono "ref" selkeyttämään attribuutin merkitystä Esimerkki (oletetaan edellisen esimerkin olemassaolo): <!ATTLIST markuprule exampleref IDREF #REQUIRED>... <markuprule exampleref="id-ja-idref-attribuutti"/> RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 211

32 IDREFS-ja IDREF-tyyppisten attribuuttien suhde vastaa edellä kuvattua NMTOKEN- ja NMTOKENS-tyyppisten attribuuttien suhdetta ENTITY--tyyppiset attribuutit viittaavat dokumentin tyyppimäärityksessä määriteltyihin entiteettien nimiin Esimerkki: <!ENTITY plant-image SYSTEM "/usr/kukka.gif"> <!ATTLIST example image ENTITY #REQUIRED>... <example image="plant-image"/> myös ENTITY- ja ENTITIES-tyyppisten attribuuttien suhde vastaa NMTOKENja NMTOKENS-tyyppisten attribuuttien suhdetta Yleisiä huomioita attribuuteista ja yhteenvetoa: - hierarkkisia attribuuttirakenteita ei ole olemassa (kuten on olemassa hierarkkisia elementtirakenteita) - XML-syntaksin näkökulmasta attribuuttien arvot ovat aina merkkijonoja - "<" ja "&" merkit on aina korvattava entiteeteillä attribuutin arvossa - attribuuttien arvot normalisoidaan RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 212

33 XML-spesifikaation nimeämät attribuutit XML-spesifikaatio määrittelee semantiikan kahdelle erikoiselle vakionimiselle attribuutille: - xml:space - xml:lang xml:space voi saada kaksi eri arvoa: default tai preserve - preserve kertoo XML-sovellukselle että sen tulee ohittaa oletusarvoinen (mielivaltainen) tyhjämerkkien sievennyskäytäntönsä ja huomioida kaikki tyhjämerkit Huomioita XML-prosessorin suorittamasta tyhjämerkkien jäsentämisestä: - XML-prosessori välittää aina kaikki (merkkidatan) tyhjämerkit sovellukselle sellaisena kuin ne olivat XML-dokumentissa - poikkeus #1: attribuuttien arvojen normalisointi - poikkeus #2: XML-prosessori korvaa mahdolliset rivinvaihdot #xd#xa ([carriage-return][line-feed]) tai #xd aina rivinvaihdolla #xa "Unixkäytännön mukaisesti" RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 213

34 xml:lang voi saada jonkin ISO 639 kielikoodin, IANA-kielikoodin (prefix "i-", "I-") tai sovelluskohtaisen kielikoodin (prefix "x-","x-") - kielikoodi kertoo (ei pakota!) elementin merkkidatan, attribuuttien arvojen ja lapsielementtien kielen (luonnollisen tai formaalin) - lapsielementit voivat ohittaa tämän kielimäärityksen oman xml:langattribuuttinsa avulla, vrt. esim. <p xml:lang="en-gb">what colour is it? <p xml:lang="en-us">or does it have color at all?</p></p> XML-dokumenteissa attribuutteja xml:space ja xml:lang (kuten mitä tahansa muitakin attribuutteja) voidaan käyttää suoraan, mutta validien dokumenttien pitää attribuutit määritellä Attribuutin xml:space julistuksen muoto on spesifikaatiossa yksikäsitteisesti määrätty, attribuutti xml:lang voidaan määritellä vapaammin: <!ATTLIST elementname xml:space (default preserve) 'preserve'> <!ATTLIST examplename xml:lang NMTOKEN 'en'> XML-standardiperhe nimeää myös muitakin attribuutteja ja esittää merkityksen näille (näihin palataan myöhemmin) RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 214

35 Notaatiojulistus Notaatiojulistus esittelee luonteeltaan semanttisen dataentiteettiin kohdistuvan sievennysmerkinnän, resurssin tai relaation dokumentin käsittelemälle tiedolle (käytännössä suhteessa XML-prosessorin ulkopuoliseen maailmaan) Notaatiojulistuksen tuottosääntö XML-spesifikaatiossa on: [82] NotationDecl ::= '<!NOTATION' S Name S (ExternalID PublicID) S? '>' [83] PublicID ::= 'PUBLIC' S PubidLiteral [75] ExternalID ::= 'SYSTEM' S SystemLiteral 'PUBLIC' S PubidLiteral S SystemLiteral Esimerkki: <!NOTATION jpgconv SYSTEM "ps2gif.exe"> <!NOTATION jpgconv SYSTEM "ps2jpg.exe"> <!ATTLIST example imagesrc NMTOKEN #REQUIRED handler NOTATION (gifconv jpgconv) #REQUIRED> <example imagesrc="ratas.ps" handler="gifconv"/> RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 215

36 Ehdolliset DTD-lohkot XML-dokumentin ulkoinen DTD-osajoukko voi sisältää ns. ehdollisen DTDlohkon ([conditional section]) Ehdollinen DTD-lohko mahdollistaa DTD:n osien kytkemisen päälle ja pois helpottaen näin laajojen dokumentin tyyppimäärittelyjen hallintaa Syntaksiltaan lohko muistuttaa CDATA-lohkoa. Lohkon näkyvyyttä kontrolloidaan avainsanojen IGNORE ja INCLUDE avulla Esimerkki kertoo kaiken: <![IGNORE[ <!ELEMENT book (comments*, title, body, supplements?)> ]]> <![INCLUDE[ <!ELEMENT book (title, body, supplements?)> ]]> Ehdollinen DTD-lohko voi sisältää periaatteessa samanlaisia merkkausjulistuksia ja merkkausta kuin DTD-osajoukotkin. On kuitenkin syytä huomata, että valinnaiset DTD-lohkot voivat olla myös sisäkkäisiä RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 216

37 Huomaa, että IGNORE-koodattu valinnainen DTD-lohko EI tarkoita samaa kuin ko. lohkon kommentoiminen dokumentin tyyppimäärittelyssä! XML-kielioppi määrää ehdollisen DTD-lohkon syntaksin seuraavasti: [61] conditionalsect ::= includesect ignoresect [62] includesect ::= '<![' S? 'INCLUDE' S? '[' extsubsetdecl ']]>' [63] ignoresect ::= '<![' S? 'IGNORE' S? '[' ignoresectcontents* ']]>' [64] ignoresectcontents ::= Ignore ('<![' ignoresectcontents ']]>' Ignore)* [65] Ignore ::= Char* - (Char* ('<![' ']]>') Char*) Validity constraint: Proper Conditional Section/PE Nesting Suurin hyöty ehdollisten DTD-lohkojen käytöstä saadaan, kun avainsana IGNORE tai INCLUDE annetaan parametrientiteetin avulla parametrina (entiteetteihin palataan pian), jolloin yksittäisen dokumentin kirjoittaja voi vielä vaikuttaa dokumentin tyyppimääritykseen: RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 217

38 Esimerkki: parametrientiteetit ja ehdolliset DTD-lohkot Dokumentin tyyppimääritys (nisakas.dtd): <!ELEMENT mammal EMPTY> <!ATTLIST mammal name NMTOKEN #REQUIRED> <![%cat;[ <!ATTLIST mammal sound (bark meow) "meow"> <!ATTLIST mammal chase (dog cat mouse) "mouse"> ]]> <![%dog;[ <!ATTLIST mammal sound (bark meow) "bark"> <!ATTLIST mammal chase (dog cat mouse) "cat"> ]]> Eläinten oletusominaisuudet voidaan nyt ottaa käyttöön määrittelemällä cat- ja dog-parametrientiteeteille sopivat arvot (monni.xml): <?xml version="1.0"?> <!DOCTYPE mammal SYSTEM "nisakas.dtd" [ <!ENTITY % dog "IGNORE"> <!ENTITY % cat "INCLUDE"> ]> <mammal name="monni"/> Sisäisessä DTD-osajoukossa esiteltävien parametrientiteettien avulla on siis mahdollista valita ulkoisesta DTD-osajoukosta jokin ehdollinen DTD-lohko RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 218

39 Yleiskäyttöinen tyyppimääritys: SYSTEM vs. PUBLIC Avainsanaa SYSTEM käyttävä dokumentin tyyppijulistus lukee siis DTD:n osaksi ulkoisen tekstitiedoston tyyliin: <?xml version="1.0"?> <!DOCTYPE mydoc SYSTEM "mydoc.dtd"> <mydoc><title>xml-dokumentti</title><body>hei vaan!</body></mydoc> Huomioita: - ulkoinen DTD-osajoukko luetaan tekstitiedostosta -...jonka suora muokkaaminen saattaa olla mahdollista (ainakin DTD:n suunnittelijalle) Dokumentin tyyppimääritysten vakiintuessa (kun DTD on suunniteltu, testattu ja havaittu hyväksi), on yleiskäyttöisyyden nimissä järkevää sijoittaa ulkoiset DTD-tiedostot paikkaan, josta ne ovat yleisesti saatavilla, esim. HTTPpalvelinhakemistoon ja käyttää DTD-osajoukkoja tyyliin: <?xml version="1.0"?> <!DOCTYPE mydoc SYSTEM " RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 219

40 Laajamittaisena tämä on kuitenkin epäkäytännöllistä ja tehotonta, etenkin jos DTD saa yleisesti hyväksyttävän standardin arvon ja kaikki viittaavat siihen! Ratkaisu: yleisesti tiedossa olevat dokumenttityypit nimetään, liitetään suoraan osaksi XML-parsereita ja DTD-osajoukko valitaan dokumentin tyyppijulistuksessa avainsanan PUBLIC avulla tyyliin: <?xml version="1.0"?> <!DOCTYPE mydoc PUBLIC "-//RAKDOK//DTD MYDOC//EN">... PUBLIC-avainsanaa seuraava literaali ei ole nyt suora viittaus tiedostoon, vaan DTD-osajoukon julkinen tunnistenimi ([public identifier]), joka sisältää seuraavat kentät: - alkaa avainsanalla "ISO" jos määrityksellä on ISO-standardin arvo - "+" jos muu merkittävä standardi, "-" jos ei ole - "//" DTD:n omistajan tunnus - "//" tiedoston tyyppi (esim. "DTD) - välilyönti " " ja dokumentin nimi - "//" kielikoodi (ISO 639) RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 220

41 Standalone-julistus Dokumentin jäsentämiseen liittyy myös tieto siitä, onko dokumentin käsittely mahdollista ilman ulkoisen DTD-osajoukon (tiedoston) lataamista Mikäli ulkoista osajoukkoa ei (kyseisen dokumentin tapauksessa) välttämättä tarvita dokumentin esiintymän lukemiseen, voidaan dokumentin alkuun XMLjulistukseen kirjoittaa riippumattomuusjulistus ([standalone declaration]): <?xml version="1.0" standalone="yes"?> Oletusarvo on "no" Joissakin tapauksissa standalone-julistus nopeuttaa dokumenttien käsittelyä Käyttö ei ole mahdollista, jos esimerkiksi: - attribuuteilla on oletusarvoja tai niiden tyyppi on jokin muu kuin CDATA - käytetään muita kuin viittä oletusentiteettiä - elementtien tietomallin tulkinta ei käy elementtirakenteesta ilmi RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 221

42 Validit XML-dokumentit Määritelmänsä mukaan XML-dokumentti ei ikinä voi olla väärin muodostettu, mutta se voi olla validi tai sitten ei Dokumentti on validi XML-dokumentti täsmälleen silloin kun: 1) dokumentti noudattaa XML-kielioppia, 2) dokumentin esittelyosa sisältää tyyppijulistuksen JA 3) dokumentin esiintymä noudattaa sitä Jos pelkkä kohta 1 toteutuu, on kyseessä ainoastaan (hyvin muodostettu) XML-dokumentti On syytä huomata, että dokumentti voi täyttää ehdon 1 vaikka se ei täyttäisikään ehtoja 2 ja 3 - tällöinkin dokumentti on XML-kielenkäytön mukaisesti pelkkä XML-dokumentti! Jotta kielenkäytössä tieto DTD-julistuksen olemassaolossa ei kuitenkaan katoaisi, on tarkoituksenmukaista ottaa käyttöön lisätermit tyyppi-validi ([typevalid]) XML-dokumentti ja ei-tyyppi-validi ([non-type-valid]) XML-dokumentti RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 222

43 Mitä DTD sitten loppujen lopuksi tarkoittaa? Suoraviivaisin tapa ymmärtää DTD:n merkitys pintaa syvemmältä on tulkita se reunaehdoksi, joka valitsee ja kiinnittää jonkin tietyn (sovelluksen näkökulmasta mielenkiintoisen) XML-dokumenttien luokan aliluokan: DOKUMENTTI- LUOKKA Z =LOOGISEN RAKENTEEN Z OMAAVAT XML- DOKUMENTIT TYYPPI-A-VALIDIT XML-DOKUMENTIT TYYPPI-C-VALIDIT XML-DOKUMENTIT TYYPPI-B-VALIDIT XML-DOKUMENTIT XML-DOKUMENTTIEN LUOKKA XML-dokumenttien luokka sisältää siis kaikki ne tekstitiedostot, jotka voidaan johtaa XML-spesifikaation kieliopista (WFC-rajoitteet huomioiden) RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 223

44 Dokumentin tyyppimääritysten kiinnittämät XML-dokumenttien luokan aliluokat ovat: 1) tyyppi-validien XML-dokumenttien suhteen aina erillisiä (ts. tyyppi-validi XML-dokumentti kuuluu aina täsmälleen yhteen dokumenttiluokkaan) 2) pelkkien XML-dokumenttien suhteen yleensä päällekkäisiä (ts. dokumentin esiintymän looginen rakenne voi olla useamman kuin yhden geneerisen dokumenttiluokan sääntöjen mukainen) Syy ensimmäiseen, ts. miksi tyyppi-validien XML-dokumenttien suhteen luokat ovat aina erillisiä, selittyy XML-dokumenttiin liitettävän dokumentin tyyppijulistuksen määräämän dokumentin tyyppimäärityksen (DTD) ainutkertaisuutena Jälkimmäisellä tarkoitetaan sitä, että yksi ja sama XML-dokumentti voi pelkän dokumentin tyyppijulistuksen lisäyksellä olla joko tyyppi-a-validi XMLdokumentti tai tyyppi-b-validi XML-dokumentti RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 224

45 Esimerkiksi seuraavat kaksi XML-dokumenttia ovat molemmat tyyppi-valideja eri tyyppimääritysten suhteen - huomaa että dokumenttien esiintymät ovat identtisiä: <?xml version="1.0"?> <!DOCTYPE mydoc [ <!ELEMENT mydoc (title, body?)> <!ELEMENT title (#PCDATA)> <!ELEMENT body (#PCDATA)> ]> <mydoc><title>hei vaan!</title></mydoc> <?xml version="1.0"?> <!DOCTYPE mydoc [ <!ELEMENT mydoc (title)> <!ELEMENT title (#PCDATA)> ]> <mydoc><title>hei vaan!</title></mydoc> Jos edellisessä esimerkissä ensimmäisen DTD:n nimeksi annetaan A ja jälkimmäisen DTD:n nimeksi B, huomataan, että: - dokumenttiluokan B XML-dokumenttien esiintymät kuuluvat aina myös dokumenttiluokkaan A mutta ei päinvastoin - annettu mv. tyyppivalidi XML-dokumentti kuuluu aina joko 1) dokumenttiluokkaan A, 2) dokumenttiluokkaan B, tai 3) ei kumpaankaan näistä RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 225

46 Yhden ja saman DTD:n voi usein yleensä esittää usean erinäköisen dokumentin tyyppijulistuksen avulla, esimerkiksi seuraavat merkkausjulistukset määrittävät saman DTD:n: <!DOCTYPE mydoc [ <!ELEMENT mydoc (#PCDATA title footer)*> <!ELEMENT title (#PCDATA)> <!ELEMENT footer (#PCDATA)> ]>... <!DOCTYPE mydoc [ <!ELEMENT mydoc (#PCDATA footer title)*> <!ELEMENT title (#PCDATA)> <!ELEMENT footer (#PCDATA)> ]> Tosin käytännössä suurten tyyppijulistusten palauttaminen toisikseen voi (käsin tehtynä) olla hankalaa Huomaa että: - XML-dokumenttien luokka sisältää potentiaalisesti äärettömän määrän dokumentteja - tyyppi-z-validien XML-dokumenttien luokka voi sisältää joko äärellisen määrän dokumentteja tai potentiaalisesti äärettömän määrän dokumentteja RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 226

47 Esimerkkejä Esimerkki äärellisen XML-dokumenttiluokan aliluokan määräävästä DTDmäärityksestä: <!DOCTYPE mydoc [ <!ELEMENT mydoc (footer?,title)> <!ELEMENT title EMPTY> <!ELEMENT footer EMPTY> ]> Esimerkkejä (potentiaalisesti) äärettömän XML-dokumenttiluokan aliluokan määräävästä DTD-määrityksestä: <!DOCTYPE mydoc [ <!ELEMENT mydoc (footer*,title)> <!ELEMENT title EMPTY> <!ELEMENT footer EMPTY> ]> <!DOCTYPE mydoc [ <!ELEMENT mydoc (#PCDATA)> ]> <!DOCTYPE mydoc [ <!ELEMENT mydoc EMPTY> <!ATTLIST mydoc attr CDATA #REQUIRED> ]> Kuten esimerkeistä voi päätellä, mielekkäät dokumenttiluokat ovat yleensä (potentiaalisesti) äärettömiä (tämä ei tarkoita että ne olisivat mielivaltaisia!) RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 227