XML-dokumenttien kommentit ovat samannäköisiä kuin HTMLdokumenteissakin: [15] Comment ::= '<!--' ((Char - '-') ('-' (Char - '-')))* '-- >'

Transkriptio

1 Kommentit XML-dokumenttien kommentit ovat samannäköisiä kuin HTMLdokumenteissakin: [15] Comment ::= '<!--' ((Char - '-') ('-' (Char - '-')))* '-- >' Esimerkki: <!-- Fix this if boss finds about me using global variables! --> Huomioita: - sisäkkäiset kommentit eivät ole sallittuja - merkkijono "--" ei saa esiintyä kommentin sisällä Huomaa, että kommentin todellakin saa kirjoittaa vain XML-kieliopin osoittamiin kohtiin (sinne missä se XML-produktioissa on erikseen mainittu - käytännössä merkkauksen ulkopuolelle), vrt: [27] Misc ::= Comment PI S Esim. datalohkojen sisälle XML-kommentteja ei voi kirjoittaa RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 176

2 XML-dokumentti on oikein muodostettu XML-dokumentti on aina oikein muodostettu ([well-formed, WF]) Spesifikaation mukaan "tekstuaalinen objekti" on (oikein muodostettu) XMLdokumentti, jos 1) se kokonaisuutena voidaan johtaa XML-kieliopin "document"-aksiomasta, 2) se toteuttaa kaikki XML-kieliopin yhteydessä asetetut WFC-rajoitteet JA 3) jokainen parsittu entiteetti johon dokumentissa viitataan, on oikein muodostettu Tämä tarkoittaa erityisesti, että: 1) XML-dokumentti sisältää aina vähintään yhden elementin 2) XML-dokumentin jäsennyspuulla on aina yksikäsitteinen juurielementti ([root]) joka ei ole minkään toisen elementin lapsi 3) elementit ovat aina aidosti sisäkkäisiä RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 177

3 Huomaa, että kyseessä on "sisäänrakennettu ominaisuus"; ei ole olemassa "väärin muodostettua XML-dokumenttia" - yhtä vähän kuin on olemassa "suorakulmaista ympyrää"; - "XML-wannabee", joka ei ole WF, on "vain" esim. ASCII-dokumentti XML-terminologiasta "puuttuu" muitakin käyttökelpoisia termejä (näihin palataan dokumenttien tyyppimääritysten yhteydessä) Käytännössä XML-dokumentin erottelu puhekielessä "XML-wannabeesta" selviää yleensä asiayhteydestä (esim. jos asiaa on tutkittu XML-parserilla) Yksinkertaisin XML-dokumentti koostuu yhdestä elementistä (prologi on optionaalinen): </shortest-dokument-ever> Lyhyin "järkevä" XML-dokumentti näyttää kuitenkin tältä: <?xml version="1.0?> <mydoc> </mydoc> Yksinkertaisin mahdollinen XML-dokumentti ei kuitenkaan ole validi XMLdokumentti - tämä edellyttää dokumentin tyyppimäärittelyn olemassaoloa RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 178

4 XML-dokumenttien parsimisesta XML-dokumentti on aina syntaktisesti XML-kieliopin mukainen ja siis aina oikein muodostettu ([well-formed, WF]) Käytännössä XML-dokumentin kirjoitusprosessissa kuitenkin saattaa tapahtua virhe, eikä lopputuloksena olekaan (WF) XML-dokumentti Huomaa, että parsimisen yhteydessä puhutaan yleensä hieman harhaanjohtavasti "XML-dokumentin" syntaksin varmistamisesta! XML-dokumentin syntaksin voi varmentaa tietenkin "käsin", mutta järkevämpää on käyttää työhön XML-parseria - parseri toimii kuten ohjelmointikielen kääntäjä ja ilmoittaa havaitut syntaksivirheet - virheilmoitukset saadaan esim. tekstimuotoisena muodossa "virheen kuvaus, rivi, sarake, korjausehdotus" - paitsi ihmislukijalle, parserin tulostus voidaan ohjata myös XMLsovellukselle (parseria voidaan käyttää "kehittyneemmin" myös jonkin ohjelmointirajapinnan läpi - tähän palataan kurssilla myöhemmin) RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 179

5 Mikäli todellakin ollaan kiinnostuneita vain oikein muodostuneisuudesta, riittää ns. ei-validoiva parseri ([non-validating parser]) - periaatteessa muuten sama kuin validoiva parseri, mutta ei tutki VCrajoitteita - teknisesti helpompi toteuttaa - koska "nykyään ohjelmia on jo saatavilla", ei yksinomaan ei-validoivien parserien käyttö välttämättä ole perusteltua (paitsi kenties ohjelmistonkehityksen tai ohjelmien lisensoinnin näkökulmasta) Kannattaa muistaa, että parserikin on vain tietokoneohjelma ja (saattaa siis) sisältää virheitä! - tietokoneet kuitenkin (yleensä) tekevät vain systemaattisia virheitä! - epäselvissä tapauksissa kannattaa kokeilla eri (pohjakooodia käyttäviä) parsereita tai viime kädessä tutkia XML-spesifikaatiota Virheellinen (tai yleensä puutteellinen) toiminnallisuus XML-editoreihin sisältyvissä parsereissa ei ole tavatonta (esim. parametrientiteettien käsittelyn suhteen) RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 180

6 XML-parsereista XML-parseriohjelmistot jakautuvat karkeasti ottaen kolmeen kategoriaan 1) komentoriviparserit 2) sovellusohjelmaan integroidut parserit (esim. XML-editori, XMLkatseluohjelma tai XML-selain) 3) oman ohjelmakoodin kautta parseriohjelman API:n (ohjelmointirajapinta, [Application Programming Interface]) läpi käytettävät parserit "Vakavasti otettavat" parserit tarjoavat "yleensä" myös oman API:nsa, joten em. vaihtoehdot eivät käytännössä ole toisensa poissulkevia Tämän lisäksi on vielä lukemattomia erilaisia tapoja paketoida ("wrapping") komentoriviparsereita osaksi esim. WWW-sivuja Luetellaan seuraavaksi muutamia "suosittuja" (perinteisiä) XML-parsereita (useimmat ladattavina paketteina toimitettavista sisältävät myös "työkalukirjastoja" yms.) RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 181

7 Lark & Larval - Lark on ei-validoiva parseri, Larval myös validoi, molemmat kirjoitettu Javalla - ks. XML for Java - Javalla toteutettu hyvä validoiva XML-parseri - ks. (etsi XML for Java) Java Project X - Javalla toteutettu hyvä validoiva XML-parseri - ks. (etsi Java Project X) TinyXML - Javalla toteutettu pieneen kokoon pyrkivä ei-validoiva XML-parseri - ks RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 182

8 RUWF expat - WWW-pohjainen ei-validoiva XML-parseri verkossa (perustuu Larkkiin) - ks. - standardi-c:llä toteutettu ei-validoiva XML-parseri (Mozilla5) - ks. Maailmalta löytyy myös (paljon, niin paljon) listoja XML-ohjelmistoista, ks. - ("täydellisin SGML/XML-referenssi") - ("selkein" yleiskatsaus XMLohjelmistoihin) - (ilmaiset XML-ohjelmat) Lisäksi uusimmat selaimet sisältävät parsereita sekä ohjelmointirajapintatoteutuksia näihin (esim. IE5, joka "sisältää" vanhan MSXML:n) RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 183

9 Parseriesimerkki: XML for Java Komentoriviparserin käyttäminen on yhtä helppoa kuin ohjelmointikielen komentorivikääntäjänkin, kunhan sopivan parseripaketin on saanut koneelleen asennettua - tarkastellaan seuraavaksi esimerkkiä XML for Java -parserin käyttämisestä XML4J on Javalla toteutettu "XML-työkalupakki" joka sisältää mm. validoivan XML-parserin (paketti löytyy esim. kirjan Goldfarb et al, the XML Handbook mukana toimitettavalta rompulta) Seuraavassa esimerkissä tarkastellaan (vanhaa) XML4J versiota (pelkän parserin käytön näkökulmasta versiolla ei nyt ole niin väliä). Parserin käyttöönoton työvaiheet ovat seuraavat: 1) tarpeelliset luokat, dokumentoinnit yms. sisältyvät pakettiin xml4j zip (1,29MB) joka puretaan kovalevylle, 2) XML4J:n käyttämiseen tarvitaan myös jokin (asennettu) Java-virtuaalikone (esim. JDK 1.1 & Swing 1.1 tai JDK 1.2) 3) parserin käyttäminen tapahtuu suorittamalla parseriluokkia Javavirtuaalikoneen avulla RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 184

10 Olkoon (syntaksivirheitä sisältävä) syötedokumenttimme (mydoc.xml) esim. <?xml version="1.0?"> <mydoc> <P>This element does no have a closing tag &undeclared_entity; <1falsetag/> </mydoc> Dokumentin syntaksivirheiden tutkiminen suoritetaan nyt (Unixissa) komennolla java -classpath 'jar/xml4j_1_1_16.jar:jar/xml4jsamples_1_1_16.jar' samples.xjparse.xjparse mydoc.xml Tällöin XML4J tulostaa: mydoc.xml: 1, 21: "?>" expected. mydoc.xml: 2, 1: Invalid XML version format, "1.0?". mydoc.xml: 2, 1: Invalid document structure. mydoc.xml: 4, 19: Undefined entity reference, "&undeclared_entity;". mydoc.xml: 5, 1: Element name expected. mydoc.xml: 6, 7: "</P>" expected RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 185

11 Virheilmoitukset kuten ohjelmointikielissä ts. ilmoitettu virheen "löytymiskohta" ei välttämättä vastaa intuitiivista käsitystä siitä, mistä virhe aiheutuu - tämän voi todeta esim. poistamalla toisen lainausmerkin testidokumentin ensimmäiseltä riviltä; tällöin XML4J tulostaa: mydoc.xml: 2, 0: Attribute value must not contain '<'. mydoc.xml: 3, 0: Attribute value must not contain '<'. mydoc.xml: 4, 19: Undefined entity reference, "&undeclared_entity;". mydoc.xml: 5, 0: Attribute value must not contain '<'. mydoc.xml: 6, 0: Attribute value must not contain '<'. mydoc.xml: 7, 3: com.ibm.xml.parser.token#getpiattributes(): Unexpected end of file. XML4J on osa IBM:n alphaworks -hanketta, joka pyrkii edistämään uusimman teknologian ja standardien käyttöönottoa tarjoamalla esim. kehitysvaiheen ohjelmistokomponentteja ohjelmistonkehittäjien käyttöön - ks. Vuoden 1999 lopulla IBM lahjoitti XML4J:n xml.apache.org -projektin käyttöön (versionumero tällöin 3.0.x ja parseri muuttui nimelle Xerces) - ks RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 186

12 Lopuksi Huomaa, että XML-dokumentin korrekti syntaksi ja "oikein muodostuneisuus" eivät takaa, että dokumentissa olisi mitään järkeä tai että dokumentti edes toteuttaisi jotain mielekästä semantiikkaa Seuraava ohjelmanpätkä on Javan syntaksin mukainen, mutta ei "järkevä": for (i=2; i<1; ++i) {s+=i;} Seuraava ohjelmanpätkä on HTML:n syntaksin mukainen, mutta ei "järkevä": <IMG SRC="painting.mypicformat" WIDTH=0 HEIGHT=0> Nyrkkisääntönä voidaan sanoa, että "hyvässä XML-dokumentissa (dokumenttiluokassa)": - valitun elementtirakenteen käyttötarkoitus ja idea on selkeästi kuvattu - tagien merkitys ja syntaksi on dokumentoitu (laajemmin kuin pelkillä DTDdeklaraatioilla) - elementtirakenne on rikas ja merkkaus on helposti luettavissa sekä johdonmukaista RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 187

13 Katso myös XML-spesifikaatio 1.0 (ks. XML:n virallinen kuvaus ja nykytilanne (ks. Yleistä XML:stä: XML.COM (ks. XML-ohjelmistoista: XMLSOFTWARE (ks. XML:ään liittyvät konferensseja, tekniikkaa, yms. alan tietoa - Graphic Communications Association (ks. Jos XML:ää haluaa käyttää johonkin sellaiseen, mihin valmisohjelmistoja ei löydy, joutuu ohjelmansa kirjoittamaan itse. Java ei ole hullumpi ratkaisu (ks. esim. Lopuksi on syytä mainita, XML 1.0 spesifikaatiolla "sellaisenaan" ei vielä pitkälle pötkitä - suurin hyöty XML:stä saadaan kun sitä käytetään menetelmänä, osana muita työprosesseja ja -standardeja RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 188

14 XML ja dokumenttien tyyppimäärittely 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 2002) luentorunko ON 189

15 XML ja dokumenttien tyyppimäärittely 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 - kirjeissä 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 2002) luentorunko ON 190

16 XML ja dokumenttien tyyppimäärittely 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 eksplisiittinen 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 "tuosta vain" RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 191

17 XML ja dokumenttien tyyppimäärittely 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ö "lähes mitä vain" Käytännössä XML:ssä dokumenttiluokat ilmaistaan XML-syntaksin mukaisen täsmällisen dokumentin tyyppideklaraation muodossa ([document type declaration]) (vrt. XML-kielen syntaksin esittäminen EBNF-muotoisena XMLkielioppina) - tyyppideklaraatio esittelee elementtien nimet, merkinnät ja dokumentin loogisen rakenteen "tuottosäännöt" XML-dokumentin tyyppideklaraatio koodaa dokumentin tyyppimäärittelyn ([document type definition, DTD]) joka formalisoi intuitiivisen dokumenttiluokan määrittämisen idean: DTD kertoo "minkätyyppisestä dokumentista on kyse" RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 192

18 XML ja dokumenttien tyyppimäärittely Tyyppideklaraation syntaksi Dokumentin tyyppimäärittely (merkinnällisesti siis tyyppideklaraatio) koostuu erityyppisistä merkkausdeklaraatiosta ([markup deklaration]) seuraavasti: - elementin tyyppideklaraatio ([element type declaration]) - attribuuttilistan deklaraatio ([attribute-list declaration]) - entiteettideklaraatio ([entity declaration]) - notaatiodeklaraatio ([notation declaration]) Dokumentin tyyppideklaraatio liitetään aina XML-dokumentin prologiin: [22] prolog ::= XMLDecl? Misc* (doctypedecl Misc*)? Tyyppideklaraatio käyttää SGML:stä tuttua DOCTYPE-koodisanaa (vrt. HTML:n tyyppimäärittely aikaisemmin): [28] doctypedecl ::= '<!DOCTYPE' S Name (S ExternalID)? S? ('[' (markupdecl PEReference S)* ']' S?)? '>' [ VC: Root Element Type ] RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 193

19 XML ja dokumenttien tyyppimäärittely Elementti- attribuutti- entiteetti- ja notaatiodeklaraatioiden ohella tyyppideklaraatioon 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 tyyppideklaraatiosta: [75] ExternalID ::= 'SYSTEM' S SystemLiteral 'PUBLIC' S PubidLiteral S SystemLiteral Käytännössä tämä tarkoittaa sitä, että dokumentin tyyppimäärittely jakautuu kahteen osaan, jotka yhdessä muodostavat dokumentin tyyppimäärittelyn: - 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ä, merkkausdeklaraatio yhdistetään ja sisäisen DTD-osajoukon esittelevät entiteetti- ja attribuuttilistadeklaraatiot tulkitaan "vahvemmiksi" kuin ulkoisen osajoukon esittelevät (elementtideklaraation päällekirjoittaminen ei ole mahdollista) RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 194

20 XML ja dokumenttien tyyppimäärittely Esimerkki: XML-dokumentti, jolla tyyppimääritys Seuraava XML-dokumentti sisältää yksinkertaisen dokumentin tyyppimäärityksen: Tiedosto myapplication.ent: <!ENTITY signature "-= life precedes knowledge =-"> Tiedosto testdocument.xml: <?xml version="1.0"?> <!DOCTYPE mydoc SYSTEM "myapplication.ent" [ <!ELEMENT mydoc (title, body)> <!ELEMENT title (#PCDATA)> <!ELEMENT body (#PCDATA)> ]> <mydoc> <title>first XML-doc</title> <body> Hello World! <&signature;> </body> </mydoc> RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 195

21 XML ja dokumenttien tyyppimäärittely Huomioita: - tiedosto testdocument.xml on (oikein muodostettu) XML-dokumentti - tiedosto myapplication.dtd on "vain" tekstitiedosto (tiedosto"päätteeksi" tosin valitaan yleensä jokin seuraavista: dtd, ent, txt) - XML-dokumentin testdocument.xml elementtirakenne sekä notaatio noudatavat DTD:ssä esitettyä (elementtien määrittelyyn palataan pian) - kysesssä on ns. validi XML-dokumentti - kyseisen dokumentin DTD koostuu sekä sisäisestä että ulkoisesta DTDosajoukosta (kumpikaan yksinään ei riitä) - XML-dokumentin prologi sisältää nyt dokumentin tyyppideklaraation - XML-dokumentin esiintymä "muuten kuten (WF) XML-dokumentissa", mutta kyseinen dokumentti ei voi olla WF (eikä siis XML-dokumentti) ilman DTD-deklaraatiota (entiteetti signature pitää esitellä) XML-dokumentin yhteydessä voidaan käyttää myös vain jompaa kumpaa DTD-osajoukkoa (valinta tehdään käytännöllisistä syistä) RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 196

22 XML ja dokumenttien tyyppimäärittely Koko DTD voidaan esitellä myös sisäisen DTD-osajoukon avulla. (Tällöin "osajoukko" on itse asiassa "koko joukko"). <?xml version="1.0"?> <!DOCTYPE mydoc [ <!ELEMENT mydoc (title, body)> <!ELEMENT title (#PCDATA)> <!ELEMENT body (#PCDATA)> ]> <mydoc> <title>first XML-doc</title> <body>hello!</body> </mydoc> Vastaavasti DTD kokonaisuudessaan voidaan "ottaa käyttöön" lukemalla merkkausdeklaraatio ("ulkoinen DTD-osajoukko") tiedostosta tyyliin (huomaa avainsana SYSTEM): <?xml version="1.0"?> <!DOCTYPE mydoc SYSTEM "mydocumentclass.dtd"> <mydoc> <title>first XML-doc</title> <body>hello!</body> </mydoc> Tällöin tekstitiedosto "mydocumentclass.dtd" sisältää rivit: <!ELEMENT mydoc (title, body)> <!ELEMENT title (#PCDATA)> <!ELEMENT body (#PCDATA)> RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 197

23 XML ja dokumenttien tyyppimäärittely Avainsana SYSTEM voidaan korvata myös sanalla PUBLIC - ero on lähinnä siinä, että PUBLIC DTD:t ovat (prosessorin) näkökulmasta "standardoituja" DTD-osajoukkojen avulla dokumenttiluokkien käsittely tehostuu: - ulkoinen DTD-osajoukko mahdollistaa yhden ja saman merkkausdeklaraatiota sisältävän tiedoston käyttämisen usean XMLdokumentin tyyppideklaraatiossa (käytännössä URL-viittauksella) - sisäisen DTD-osajoukon avulla on usein kätevää suunnitella merkkausdeklaraatiota ja toisaalta täsmentää dokumentin tyyppimääritystä (esim. entiteettien ja attribuuttien osalta) Kaikkea mahdollista merkkausdeklaraatiota 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 2002) luentorunko ON 198