9 XML 1.0 - perusteet XML jakaa dokumenttien käsittelyn kaksitasoiseksi prosessiksi, jossa XMLprosessori ([processor]) lukee XML-dokumentin ja välittää tämän jäsennettynä sovellukselle ([application]). Käytännössä: - XML-prosessori ymmärtää XML-dokumentin syntaksin, tunnistaa sen loogisen rakenteen ja osaa tämän perusteella tuottaa auki kirjoitetun XMLdokumentin jäsennyspuun - sovellus käsittelee XML-dokumentin tietoa prosessorin avustuksella (yleensä jäsennyspuun perusteella) ja tekee jotain <EX> This document is yet <IMG SRC="a"> another TEX My EXA CON AUT Bill 0100100000 1010010110 1010100101 0110001010 1011001010 1001010010 XML-DOKUMENTTI XML-PROSESSORI SOVELLUS TULOS XML 1.0 -spesifikaatio ei määrittele sovelluksen toimintaa käytännössä lainkaan (eikä siten XML-sovellusalueita) vaan keskittyy XML-prosessorin efektiivisen käyttäytymisen (ja virhetilanteiden) kuvailuun Merkintäkielenä XML muistuttaa suuresti HTML:ää, mutta on tätä huomattavasti johdonmukaisempi (ja muodollisempi) XML-dokumenttien fyysinen rakenne muodostuu ns. entiteeteistä ([entity] - entiteetti=tiedoston laiteriippumaton abstraktio - kaksi pääluokkaa: XML-kieliopin mukaiset tekstientiteetit ([parsed entity]) vs. dataentiteetit ([unparsed entity]) - tekstientiteetit koostuvat edelleen merkeistä ([character]), jotka jakautuu merkkidataksi ([character data]) ja merkkaukseksi ([markup]) XML erottelee merkkauksen ja merkkidatan merkkien koodauksella: merkkaus määrittää dokumentin loogisen rakenteen Merkkauksen erottelu merkkidatasta on tuttua: kaikki '<'-merkillä alkava on merkkausta (poikkeustapauksissa koodaus on hoidettu jollakin muulla systemaattisella tavalla) 73275 RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 143 73275 RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 144 XML-dokumenttien merkkauksesta XML-dokumenttien merkkaus ([markup]) voi olla jotakin seuraavista: - prosessointiohje - dokumentin tyyppimäärittely - elementin alkutagi - elementin lopputagi - tyhjän elementin tagi - entiteettiviittaus - merkkiviittaus - kommentti - CDATA-lohko Kaikki muu tekstientiteettien sisältö on merkkidataa EBNF-notaatio tarjoaa selkeän tavan määritellä XML-dokumentin osat yksikäsitteisesti; XML-spesifikaatio määrittelee yhden ja ainutkertaisen 89 (sievennettyä) tuottosääntöä sisältävän XML-kieliopin, joka - yksikäsitteisesti luettelee XML-dokumenttien kaikki lailliset merkit - esittelee XML-käsitteet täsmällisesti (esim. nimien muodostamiseen käytettävä tuottosääntö "Name") - ja osoittaa dokumenttien muodostussäännöt (eritoten "document"- tuottosääntö) XML-dokumentti on merkkijono, jonka XML-kieliopin määrittämän kielen sanoja tunnistava automaatti hyväksyy Jokainen XML-dokumentti voidaan johtaa XML:n kieliopin "document"- aksioomasta (tuottosääntöjen numerointi seuraa XML 1.0 -spesifikaatiota): [1] document ::= prolog element Misc* XML-dokumentti koostuu oleellisesti prologista sekä yksikäsitteisestä juurielementistä XML-merkkauksessa kirjaimen koolla on merkitys 73275 RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 145 73275 RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 146
kolme eri elementtiä sisäkkäin <Element> <ELEMENT> <element> </element> </ELEMENT> </Element> Tyhjämerkin ([white space]) tulkinta vaihtelee eri kohdissa dokumenttia, esim. - moninkertaiset tyhjämerkit jätetään huomiotta elementtien sisällä nimen ja attribuuttien välillä - tyhjämerkillä on merkitys elementtien sisällä - tyhjämerkit normalisoidaan joissakin attribuuttiarvoissa (tähän palataan myöhemmin) [3] S ::= (#x20 #x9 #xd #xa)+ Elementtien alku- tai lopputagien poisjättäminen ei merkkauksessa ole sallittua (muitakaan sievennysmerkintöjä ei XML:ssä juuri ole) Elementtien attribuuttien arvot annetaan vakiomerkkijonoina, joita ympäröivät aina lainaus- tai heittomerkit <elem attr-a="123" attr-b='abc'>hei vaan!</elem> XML erottelee selvästi myös esim. merkistöihin, elementtien nimeämiseen ja attribuuttien arvoihin liittyviä termejä: - nimi ([name]) - tunnistemerkkijono ([name token]) [4] NameChar ::= Letter Digit '.' '-' '_' ':' CombiningChar Extender [5] Name ::= (Letter '_' ':') (NameChar)* [7] Nmtoken ::= (NameChar)+ Muut em. tuottosäännöissä esiteltävät käsitteet määrittelevät (luettelevat) ne Unicode-indeksit (merkkiluokat), jotka vastaavat termejä "Letter", "Digit", "CombiningChar" ja "Extender", jne. Nimiä käytetään tyypillisesti elementtien nimeämiseen, tunnistemerkkijonoja taas esim. attribuuttien arvoalueen rajaamiseen XML varaa yleensä nimien prefixarvot [xx][mm][ll] omaan käyttöönsä (esim. "xml-element" ei siis ole laillinen elementin nimi) 73275 RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 147 73275 RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 148 Nimissä "xml"-alkuisiin merkkijonoihin liittyy yleensä jokin oletussemantiikka: nimiä käytetään esim. XML-perheen sisäisiin viittauksiin sitomaan eri spesifikaatioita yhteen (tyylien käyttö, nimiavaruudet, jne.) Teksti elementtien sisällä saa koostua lähes mistä tahansa merkeistä, tagien sisällä sallittujen merkkien lukumäärää on rajattu: attribuuttien arvot yms. tunnisteet asetetaan vakiomerkkijonojen ([literal string]) avulla. Vakiomerkkijonojen rajoittimina käytetään tuttuun tapaan joko lainaus- tai heittomerkkejä Esimerkkejä: "Double quoted literal" 'Single quoted literal' "What comes after 90'?" 'We shall meet at 20"' Monimutkaisten attribuuttiarvojen antamiseen saatetaan tarvita entiteetti- tai merkkiviittauksia (näihin palataan pian) XML-dokumentin yleisrakenne XML-dokumentti jakautuu siis kahteen osaan: esittelyyn ja esiintymään [1] document ::= prolog element Misc* Esittely ([prolog]) - XML-versionumero, koodaustapa, riippumattomuusjulistus - dokumentin tyyppijulistus Esiintymä ([instance]) - dokumentin sisältö (dokumentin juurientiteetti) mahdollisen tyyppikuvauksen rajoittaman loogisen rakenteen puitteissa Dokumentin looginen rakenne kuvataan tagien merkitsemien elementtien muodossa Elementtien muodostama rakenne on hierarkkinen ja siten aidosti sisäkkäinen XML-dokumentti ei määritä omaa semantiikkaansa (merkitystä), vaan ainoastaan paljaan rakenteen, johon informaatio on "ripustettu" 73275 RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 149 73275 RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 150
dokumentin looginen rakenne ESITTELY ESIINTYMÄ <?xml version="1.0"?> <!DOCTYPE example SYSTEM "hellow.dtd"> <example> <title>hei maailma!</title> <content> <text>ensimmäinen XML-dokumentti</text> <author>jukka</author> </content><date/> </example> Esimerkki vastaa rakennetta: title Hei text Ensimmä example content author Jukka 73275 RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 151 date Esittely XML-dokumentti alkaa aina dokumentin esittelyosalla: [22] prolog ::= XMLDecl? Misc* (doctypedecl Misc*)? Esittely kuvaa ko. XML-dokumentin (läh. koodauksen) sekä esittelee mahdollisen dokumentin tyyppijulistuksen ([document type declaration, DTD]) Vaikka useimpien XML-elementtien sisällä voi olla ns. prosessointiohjeita ([prosessing instruction, PI], näihinkin palataan vielä), esitellään yleensä näistä tärkeimmät juuri prologissa [27] Misc ::= Comment PI S Esittely, jos sellainen dokumenttiin kirjoitetaan, alkaa aina XML-julistuksella: [23] XMLDecl ::= '<?xml' VersionInfo EncodingDecl? SDDecl? S? '?>' Ensimmäinen XML-julistuksen kenttä kertoo käytetyn XML-version; toistaiseksi on olemassa vain versionumero 1.0: [24] VersionInfo ::= S 'version' Eq ("'" VersionNum "'" '"' VersionNum '"') 73275 RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 152 Toinen kenttä kertoo dokumentin esitykseen käytettävän koodauksen: [80] EncodingDecl ::= S 'encoding' Eq ('"' EncName '"' "'" EncName "'" ) [81] EncName ::= [A-Za-z] ([A-Za-z0-9._] '-')* /* Encoding name contains only Latin characters */ Mikäli koodausta ei ilmoiteta (tai osata tunnistaa XML-dokumentin juurientiteettiä vastaavan tiedoston alusta), oletetaan UTF-8 (prosessorituen pitäisi löytyä ainakin Unicode-koodauksille UTF-8 ja UTF-16) <?xml version="1.0" encoding="utf-16"?> Lopuksi esitellään tieto siitä, selviääkö dokumentin validius dokumentin sisältämien tietojen perusteella ([Standalone Document Declaration, SDD]) [32] SDDecl ::= S 'standalone' Eq (("'" ('yes' 'no') "'") ('"' ('yes' 'no') '"')) [ VC: Standalone Document Declaration ] XML-deklaraatiota seuraa esittelyosassa mahdollinen dokumentin tyyppikuvaus (tähän palataan yksityiskohtaisesti seuraavassa luvussa) 73275 RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 153 Ainoa todellinen syy XML-julistuksen valinnaisuudelle on se, että XMLdokumentteja voitaisiin käyttää joidenkin HTML- ja SGML-sovellusten yhteydessä (sekoittamatta näitä oudolla XML-koodeilla) - XML-prosessointiohjeiden syntaksi on vastaava kuin SGML:ssä, mutta merkitystä ei (välttämättä) ole määritelty - XML-prosessointiohje on HTML:n näkökulmasta syntaksivirhe (vaikka esim. selain sen sivuuttaisikin) Vaikka esittelyosan voisi periaatteessa jättää poiskin, kannattaa dokumentin alkuun aina liittää minimaalinen XML-julistus: <?xml version="1.0"?> XML-dokumentit edustavat pyrkimystä kohti itsenäisesti tunnistettavissa olevia ([self-identifying]) dokumentteja - ei tarvetta tiedostopäätteille tms. Huomaa, että vaikka esittelyosan syntaksi näyttää ulkoisesti attribuuttien syntaksilta, ei se sitä ole (esim. koodien "version" ja "encoding" järjestystä ei saa vaihtaa) XML-julistus ei itse asiassa ole mitään muuta kuin erityinen XML-prosessorille tarkoitettu XML-prosessointiohje 73275 RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 154
Elementit XML-elementit ovat heti tuttuja HTML-kielitaitoisille: <element attribute="value">content</element> XML-elementin erikoistapaus on tyhjä elementti: <empty attribute="value"/> Elementtejä rajaavat alku- ja lopputagit; tyhjällä elementillä on oma ainokainen taginsa eikä lainkaan sisältöä: [39] element ::= EmptyElemTag STag content ETag [ WFC: Element Type Match ] [ VC: Element Valid ] Huomaa elementtien rajoitteet: - alku- ja lopputagien nimien tulee vastata toisiaan - dokumentin tyyppimäärityksen (mahdollisesti) mukanaan tuomat rajoitteet Elementeillä on aina nimi (itse asiassa elementin tyypin nimi ([generic identifier, GI])), nimen on esiinnyttävä sekä elementin alku- että lopputageissa [40] STag ::= '<' Name (S Attribute)* S? '>' [ WFC: Unique Att Spec ] [42] ETag ::= '</' Name S? '>' Tyhjän elementin tagi on hyvin samanlainen kuin normaali elementin alkutagi: [44] EmptyElemTag ::= '<' Name (S Attribute)* S? '/>' [ WFC: Unique Att Spec ] Tyhjän elementin saa kirjoittaa myös alku- ja lopputagien avulla (tällöin tagien väliin ei saa jäädä edes tyhjämerkkiä): <empty attribute="value"></empty> Validien dokumenteissa elementtirakenne (sallittujen elementtien tyyppi ja sallittu elementtirakenne) voidaan määrätä dokumentin tyyppikuvauksessa XML-dokumentissa on aina vähintään yksi elementti: juurielementti 73275 RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 155 73275 RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 156 Attribuutit Myös XML-elementtien attribuuttien syntaksi on tuttua (muista tosin aina lainaus- tai heittomerkit!): <element attribute="value">content</element> Yhdellä elementillä voi olla monta eri attribuuttia, järjestyksellä ei ole väliä <second-element a="first" b='second'>content</second-element> Erityyppisillä elementeillä voi olla samannimisiä (samantyyppisiä) attribuutteja - teknisesti ottaen kyse on kuitenkin eri attribuuteista <first-element version="1.0">content</first-element> <second-element version="1.1">content</second-element> Attribuuttien nimet määräytyvät kuten elementeillä: [41] Attribute ::= Name Eq AttValue [ VC: Attribute Value Type ] [ WFC: No External Entity References ] [ WFC: No < in Attribute Values ] Attribuutin arvon sijoitusoperaattorina toimii tuttuun tapaan yhtäsuuruusmerkki [25] Eq ::= S? '=' S? XML-dokumenteissa elementeille voidaan pakottaa attribuutteja, antaa näille oletusarvoja sekä kiinnittää attribuuttien arvoalueita Tiedon jakaminen elementtien ja attribuuttien välillä on periaatteessa mielivaltaista, systemaattinen rajanveto kuitenkin helpottaa dokumenttien kirjoittamista ja lukemista Hyvä nyrkkisääntö: - attribuutit ovat konkreettisten elementtien (esim. muistion sisältö) abstrakteja ominaisuuksia (esim. päivämäärä) - attribuuttien arvot annetaan dialogien avulla avainsanalistoina tai kytkiminä, elementtien sisällön kirjoittamiseen käytetään omia erikoistuneita editoreitaan Käytännössä XML-dokumenttien suunnittelussa valinta tehdään seuraavien XML:n ominaisuuksien perusteella - hierarkkisten rakenteiden määrittely onnistuu ainoastaan elementtirakenteiden muodossa 73275 RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 157 73275 RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 158
Lisäksi - attribuuttirakenteiden yhdistäminen on elementtirakenteiden yhdistämistä helpompaa - attribuuttirakenteen mallintaminen on perus-xml:ssä rajoitettua - pitkien attribuuttien kirjoittaminen on käytännössä hankalaa - dokumenttia halutaan kirjoittaa osissa; dokumentin jakaminen osiksi onnistuu helpommin elementtien kuin attribuuttien perusteella - "attribuuttien arvoihin viittaaminen prosessorissa X on helpompaa kuin elementin sisältöön viittaaminen" - "prosessori Y ei osaa käsitellä dokumenttiani/elementtejäni/attribuuttejani jos valitsen tietorakenteeksi muun kuin Z:n" Lopulta kyse on sovelluskohtaisesta valinnasta ja kohdeyleisöstä (ja sen odotuksista) Yleensä saman asian voisi periaatteessa esittää elementteihin tai attribuutteihin nojautuvan tietorakenteen avulla, mutta käytännössä vain toinen lähestymistapa on järkevä Entiteetit ja merkkiviittaukset Merkkaus varaa käytännössä käyttöönsä merkit {<,>,",', } ja siten rajoittaa ja hankaloittaa sisällön kirjoittamista Tätä silmälläpitäen XML sisältää etukäteen määriteltyjä entiteettejä sekä mekanismin jolla tehdä entiteetti- ja merkkiviittauksia [67] Reference ::= EntityRef CharRef Entiteettien syntaksi on sama kuin HTML:ssäkin: [68] EntityRef ::= '&' Name ';' [ WFC: Entity Declared ] [ VC: Entity Declared ] [ WFC: Parsed Entity ] [ WFC: No Recursion ] Esimerkiksi Acme näyttää tältä: Acme 73275 RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 159 73275 RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 160 Yhden merkin mittaisia (sisäisiä teksti-) entiteettejä ei välttämättä tarvittaisi; samaan lopputulokseen päästään myös merkkiviittauksilla ([character reference]). Entiteettien käyttö tekee dokumenteista tosin luettavampia [66] CharRef ::= '&#' [0-9]+ ';' '&#x' [0-9a-fA-F]+ ';' [ WFC: Legal Character ] Acme Etukäteen määritellyt entiteet ([predefined entities]) ovat: nimi merkki amp & lt < gt > apos ' quot " <example>xml-tagin aloittava merkki: <</example> Kaikki muut entiteetit on määriteltävä (mahd. välillisesti) dokumentin esittelyosassa (vrt. HTML!) tämä ei kuitenkaan aiheuta (oikeiden XML-editorien tapauksessa yleensä) ongelmia, sillä XML tukee Unicodea ja siten suoraan esim. skandinaavisia kirjaimia Entiteettien apos ja quot avulla erityisesti myös attribuuttien arvoihin on helppo sisällyttää monimutkaisia lainaus- ja heittomerkkirakenteita (attribuuttien arvojen jäsentämiseen ja tähän liittyviin sääntöihin palataan myöhemmin) Entiteettien idea on siinä, että XML-prosessori välittää halutun tiedon XMLsovellukselle jäsentäen entiteettiviittaukset auki (sovellus ei näe "<" vaan "<") Entiteetit mahdollistavat esim. "<"-merkin sisällyttämisen elementtien sisällöksi, mutta suurten tekstitiedostojen koodaaminen näin on vaivalloista (paitsi jos koodauksen hoitaa tietokoneohjelma), ks. ongelmallinen esimerkki: cout << "i=" << setw(3) << i << "units\n"; Ratkaisu: merkkidatalohkojen käyttö 73275 RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 161 73275 RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 162
Merkkidatalohkot CDATA-lohko on merkitty osa elementin sisältöä, joka saa sisältää mitä tahansa muita merkkejä paitsi datalohkon päättävän merkkijonon "]]>" [18] CDSect ::= CDStart CData CDEnd [19] CDStart ::= '<![CDATA[' [20] CData ::= (Char* - (Char* ']]>' Char*)) [21] CDEnd ::= ']]>' <![CDATA[ for (i=0; i<lim; ++i) if (buf[i]>def) fun(buf[i]); ]]> Merkkidatalohkoa luetaan sellaisenaan, eikä sen katsota sisältävän lainkaan muuta XML-merkkausta <![CDATA[ <p>tämä on <b>vain ja ainoastaan</b> tekstiä ]]> 73275 RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 163 Vaaranpaikka piilee datalohkon päättävässä "]]>"-merkkijonossa Esimerkiksi tekstinpätkä if (buffer[index[i]]>lim) fun(i); pitäisi datalohkona koodata (esimerkiksi) muodossa <![CDATA[if (buffer[index[i]]]><!cdata[]>lim) fun(i);]]> Esimerkkitapauksessa kätevämpää lienee kuitenkin kirjoittaa entiteetin lt avulla koodi muodossa: if (buffer[index[i]]>lim) fun(i); Tilanne on ongelmallinen lähinnä XML-dokumentteja käsin kirjoittavalle - ohjelmallisesti koodaus on helppo piilottaa On syytä muistaa, että datalohkon sisältö todella on jäsentämätöntä merkkidataa ([character data, CDATA]), joten myöskään entiteetti- tai merkkiviittauksia ei voi käyttää (saattaa aiheuttaa ongelmia ASCII-editoreita käyttäville) Datalohkon voi kirjoittaa sinne minne merkkidatan kirjoittaminenkin on sallittua (datalohko tulkitaan XML-merkkaukseksi) 73275 RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 164 Prosessointiohjeet Prosessointiohjeiden ([processing instruction, PI]) tarkoituksena on tarjota standardi mekanismi tekstimuotoisen ohjaustiedon välittämiseen XMLprosessorin ohi suoraan sovelluksen käsiteltäväksi [16] PI ::= '<?' PITarget (S (Char* - (Char* '?>' Char*)))? '?>' [17] PITarget ::= Name - (('X' 'x') ('M' 'm') ('L' 'l')) Käytännössä prosessointiohjeiden avulla on mahdollista tuoda XMLdokumentteihin sovelluskohtaista merkkausta (mikä yleisesti ottaen huono idea) Hypoteettinen esimerkki (PITarget yksilöi koodin käsittelijän): Tekstiä ja<?my-formatter font-size="16"?>suurta tekstiä Vaikka PI-merkkauksen käyttöä tuleekin välttää, on se käyttökelpoista jos esimerkiksi: - dokumentteja käsitellään joka tapauksessa tietyllä ohjelmalla - PI-merkkaus ei dokumentin loogisen rakenteen puitteissa muuten onnistu 73275 RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 165 Prosessointiohjauksen sijaan kannattaa yrittää suunnitella rakenteellisempia ratkaisuja ja dokumenttien muuntamista halutun ohjelman ymmärtämään muotoon On kuitenkin myös tilanteita, joissa vaihtoehdot ovat tylyt: joko töiden lopettaminen kokonaan tai PI-merkkauksen käyttö: - dokumenttien tyyppimäärityksen muuttaminen ei ole mahdollista (esim. yleisesti käytössä oleva DTD) - XML itse sitä vaatii Yleensä käytettäviä prosessointiohjeita ovatkin - XML-julistus - XML-standardiperheeseen liittyvät prosessointiohjeet Kannattaa tosin huomata, että XML-julistusta ei XML-kieliopissa johdeta tuottosäännöstä 16, vaan tuottosäännöstä 23, joka käytännössä kiinnittää ko. erikoisen ja läheisesti juuri XML-prosessorin toimintaan liittyvän PI:n Mikäli omaa merkkausta ylipäänsä pitää ottaa käyttöön, kannattaa se ehdottomasti tehdä PI-muodossa eikä XML-kommentteina! (vrt. HTML) 73275 RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 166
Kommentit XML-dokumenttien kommentit ovat samannäköisiä kuin HTMLdokumenteissakin: [15] Comment ::= '<!--' ((Char - '-') ('-' (Char - '-')))* '-- >' <!-- Tämä on kommentti --> 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-tuottosäännöissä on erikseen mainittu - käytännössä merkkauksen ulkopuolelle), ks. esimerkiksi: [27] Misc ::= Comment PI S Esim. merkkidatalohkojen sisälle XML-kommentteja ei voi kirjoittaa 73275 RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 167 XML-dokumentti on oikein muodostettu XML-dokumentti on aina hyvin muodostettu ([well-formed, WF]) Spesifikaation mukaan tekstidokumentti on (hyvin muodostettu) XMLdokumentti, jos 1) se voidaan kokonaisuutena johtaa XML-kieliopin "document"- aksioomasta, 2) se toteuttaa kaikki XML-kieliopin yhteydessä asetetut WFC-rajoitteet JA 3) jokainen tekstientiteetti, johon dokumentissa viitataan, on hyvin 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ä 73275 RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 168 Huomaa, että väärin muodostettua XML-dokumenttia ei ole olemassa - yhtä vähän kuin on olemassa suorakulmaista ympyrää; - XML-wannabee, joka ei ole WF, on pelkkä tekstidokumentti 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-jäsentimellä) Yksinkertaisin XML-dokumentti koostuu yhdestä elementistä (esittelyosa on valinnainen): <shortest-dokument-ever/> XML-dokumenttiin on kuitenkin aina syytä lisätä XML-julistus: <?xml version="1.0?> <mydoc> </mydoc> Yksinkertaisin mahdollinen XML-dokumentti ei kuitenkaan ole validi XMLdokumentti - tämä edellyttää dokumentin tyyppimäärittelyn olemassaoloa XML-dokumenttien jäsentämisestä XML-dokumentti on aina XML-kieliopin mukainen ja siis aina hyvin muodostettu ([well-formed, WF]) Käytännössä XML-dokumentin kirjoitusprosessissa kuitenkin saattaa tapahtua virhe, eikä lopputuloksena olekaan (WF) XML-dokumentti XML-dokumentin syntaksin voi tarkastaa tietenkin tuottosääntöjen avulla, mutta järkevämpää on käyttää työhön XML-jäsennintä - jäsennin toimii kuten ohjelmointikielen kääntäjä ja ilmoittaa havaitut syntaksivirheet - virheilmoitukset saadaan esim. tekstimuotoisena muodossa "virheen kuvaus, rivi, sarake, korjausehdotus" - paitsi ihmislukijalle, jäsentimen tulostus voidaan ohjata myös XMLsovellukselle (jäsennintä voidaan käyttää myös jonkin ohjelmointirajapinnan läpi) 73275 RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 169 73275 RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 170
Mikäli todellakin ollaan kiinnostuneita vain oikein muodostuneisuudesta, riittää ns. ei-validoiva jäsennin ([non-validating parser]): - periaatteessa muuten sama kuin validoiva jäsennin, mutta ei tutki VCrajoitteita - teknisesti helpompi toteuttaa - ei-validoivan jäsentimen käyttäminen ei yleensä ole järkevää (paitsi kenties ohjelmistonkehityksen tai ohjelmien lisensoinnin näkökulmasta) Kannattaa muistaa, että jäsenninkin on vain tietokoneohjelma ja (saattaa siis) sisältää virheitä! - tietokoneet kuitenkin (yleensä) tekevät vain systemaattisia virheitä! - epäselvissä tapauksissa kannattaa kokeilla eri jäsentimiä tai viime kädessä tutkia XML-spesifikaatiota Virheellinen (tai yleensä puutteellinen) toiminnallisuus XML-editoreihin sisältyvissä jäsentimissä ei ole tavatonta (esim. parametrientiteettien käsittelyn suhteen) XML-jäsentimistä XML-parseriohjelmistot jakautuvat karkeasti ottaen kolmeen kategoriaan 1) komentorivijäsentimet 2) sovellusohjelmaan integroidut parserit (esim. XML-editori, XMLkatseluohjelma tai XML-selain) 3) oman ohjelmakoodin kautta jäsenninohjelman API:n (ohjelmointirajapinta, [Application Programming Interface]) läpi käytettävät jäsentimet Vakavasti otettavat jäsentimet tarjoavat usein 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") komentorivijäsentimiä osaksi esim. WWW-sivuja Luetellaan seuraavaksi muutamia suosittuja (perinteisiä) XML-jäsentimiä (useimmat valmiina paketteina toimitettavista sisältävät myös erilaisia työkalukirjastoja yms.) 73275 RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 171 73275 RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 172 Xerces-J - hyvä Java-pohjainen jäsenninkirjasto - tulee myös nimiavaruuksia ja validointia XML-skeeman suhteen - ks. http://xml.apache.org/xerces-j/ Lark & Larval - Lark on ei-validoiva jäsennin, Larval myös validoi, molemmat kirjoitettu Javalla - ks. http://www.textuality.com/lark/ RUWF - WWW-pohjainen ei-validoiva XML-jäsennin verkossa - ks. http://www.xml.com/pub/a/tools/ruwf/check.html expat - standardi-c:llä toteutettu ei-validoiva XML-parseri - ks. http://www.jclark.com/xml/expat.html Maailmalta löytyy myös (paljon, niin paljon) listoja XML-ohjelmistoista, ks. - http://www.oasis-open.org/cover/ (hyvä SGML/XML-referenssi) - http://www.xmlsoftware.com/parsers.html (selkeä yleiskatsaus XMLohjelmistoihin) - http://xml.apache.org/ (laadukkaita XML-sovelluksia) - http://www.garshol.priv.no/download/xmltools/ (ilmaiset XML-ohjelmat) Lisäksi uusimmat selaimet sisältävät jäsentimiä sekä ohjelmointirajapintatoteutuksia näihin (esim. IE5 sisältää MSXML:n) 73275 RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 173 73275 RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 174
Esimerkki jäsentimestä: Xerces-J Komentorivijäsentimen käyttäminen on yhtä helppoa kuin ohjelmointikielen komentorivikääntäjänkin, kunhan sopivan jäsenninpaketin on saanut koneelleen asennettua - seuraavassa esimerkki Xerces-J-jäsentimen käyttämisestä Xerces-J on Javalla toteutettu XML-työvälineiden kokoelma, joka sisältää mm. validoivan XML-jäsentimen (paketti löytyy Apache XML -projektin kotisivulta, ks. http://xml.apache.org/xerces2-j/) Jäsentimen käyttöönoton työvaiheet ovat seuraavat (käytössä on Xerces-J:n versio 2.6.1): 1) tarvittavat luokat, dokumentoinnit yms. sisältyvät pakettiin Xerces-Jbin.2.6.1.zip (5,47MB), joka puretaan kovalevylle, 2) Xerces-J:n käyttämiseen tarvitaan myös jokin (asennettu) Javavirtuaalikone (vähintään JDK 1.2 tai uudempi) 3) Xerces-J:n sisältämän jäsentimen käyttäminen komentoriviltä tapahtuu pakettiin sisältyvien esimerkkiohjelmien avulla (esim. sax.counter tai sax.documenttracer) 73275 RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 175 Olkoon (syntaksivirheitä sisältävä) syötedokumenttimme (doc.xml) esim. <?xml version="1.0" encoding="iso-8859-1"> <dokumentti> <p>tällä elementillä ei ole lopputagia &maarittelematon-entiteetti; <1virheellinennimi/> </dokumentti> Dokumentin syntaksivirheiden tutkiminen suoritetaan nyt (DOS-ikkunassa) komennolla java -classpath xercessamples.jar;xercesimpl.jar sax.counter doc.xml Tällöin (sax.counter-esimerkkiohjelman käyttämä) Xerces-J tulostaa: [Fatal Error] doc.xml:1:42: A pseudo attribute name is expected. Jaa mitä? Virheilmoitus ei (ohjelmointikielten komentorivikääntäjien tapaan) välttämättä kerro virheen aiheuttajaa selkokielellä. Rivin ja kirjaimen numero ohjaavat kuitenkin virheen jäljille: "?"-merkki puuttuu xml-julistuksen perästä. 73275 RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 176 Lisätään puuttuvat merkki ja yritetään uudestaan: [Fatal Error] doc.xml:4:31: The entity "maarittelematon-entiteetti" was referenced, but not declared. Entiteetin määrittely puuttuu. Vaihdetaan entiteettiviittaus XML-kieleen sisältyvään lt-entiteettiin ja jatketaan: [Fatal Error] doc.xml:5:4: The content of elements must consist of well-formed character data or markup. Varsin yleinen virheilmoitus, josta ei taaskaan suoraan selviä virheen varsinainen aiheuttaja. Ratkaisu löytyy XML-spesifikaatiosta: elementin nimen on oltava Name-tuottosäännön mukainen, ks. [5] Name ::= (Letter '_' ':') (NameChar)* Seuraava yritys tuottaa lopulta järkevän korjausehdotuksen sisältävän virheilmoituksen: [Fatal Error] doc.xml:6:3: The element type "p" must be terminated by the matching end-tag "</p>". Lisätään p-elementin lopputagi virheilmoituksen mukaisesti. Dokumentti on nyt (hyvin muodostettu) XML-dokumentti, joten XML-jäsennin pääsee dokumentin 73275 RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 177 loppuun asti ilman virheitä ja sax.counter tulostaa keräämänsä tilastotiedot dokumentista: doc.xml: 440 ms (3 elems, 0 attrs, 0 spaces, 45 chars) Syötedokumentti (doc.xml) korjausten jälkeen: <?xml version="1.0" encoding="iso-8859-1"?> <dokumentti> <p>tällä elementillä ei ole lopputagia < <virheellinennimi/> </p> </dokumentti> Opetus: XML-jäsentimen käyttäminen helpottaa virheiden etsimistä dokumenteista mutta virheilmoitusten tulkitseminen edellyttää usein XMLkielen perusteiden hallintaa Xerces-J on osa Apache XML -projektia, joka pyrkii edistämään XML:n käyttöä toteuttamalla vapaasti saatavilla olevia, laadukkaita ja standardien mukaisia XML-sovelluksia soveltajien käyttöön, ks. http://xml.apache.org/ 73275 RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 178
Lopuksi Huomaa, että XML-dokumentin oikea syntaksi ei takaa sitä, että dokumentissa olisi mitään järkeä tai että dokumentti edes toteuttaisi jotain mielekästä semantiikkaa Ote ohjelmakoodista, joka on Javan syntaksin mukainen mutta ei järkevä: for (i=2; i<1; ++i) {s+=i;} Ote merkkauksesta, joka on HTML:n syntaksin mukainen mutta ei järkevä: <img src="image.jpg" width="0" height="0" alt="tyhjä"/> 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ä DTDjulistuksilla) - elementtirakenne on riittävän rikas ja merkkaus on helposti luettavissa sekä johdonmukaista 73275 RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 179 Katso myös XML-spesifikaatio 1.0 (ks. http://www.w3.org/tr/rec-xml) XML:n virallinen kuvaus ja nykytilanne (ks. http://www.w3.org/xml/activity.html) Yleistä XML:stä: XML.COM (ks. http://www.xml.com) XML-ohjelmistoista: XMLSoftware (ks. http://www.xmlsoftware.com/) XML:ään liittyvät konferensseja, tekniikkaa, yms. alan tietoa - IDEAlliance (International Digital Enterprise Alliance) (ks. http://www.idealliance.org/) Jos XML:ää haluaa käyttää johonkin sellaiseen, mihin valmisohjelmistoja ei löydy, joutuu ohjelmansa kirjoittamaan itse. Java ei ole hullumpi ratkaisu (ks. esim. http://www.java.sun.com/) 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 73275 RAKENTEISET DOKUMENTIT (kevät 2004) luentorunko ON & JH 180