<Element> <ELEMENT> <element> </element> </ELEMENT> </Element>

Transkriptio

1 EBNF-notaatio tarjoaa selkeän tavan määritellä XML-dokumentin osat yksikäsitteisesti; XML-spesifikaatio määrittelee yhden ja ainutkertaisen 89 (sievennettyä) produktiota sisältävän XML-kieliopin, joka - yksikäsitteisesti luettelee XML-dokumenttien kaikki lailliset merkit - esittelee XML-käsitteet täsmällisesti (esim. "nimi" Name) - ja osoittaa "dokumenttien muodostussäännöt" (eritoten produktio "document") 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 aksiomasta "document" (produktioiden numerointi seuraa XML 1.0 -spesifikaatiota): [1] document ::= prolog element Misc* XML-dokumentti koostuu oleellisesti prologista sekä yksikäsitteisestä juurielementistä XML erottelee tunnisteet ja nimet isojen ja pienten kirjainten perusteella RAKENTEISET DOKUMENTIT (kevät 2003 luentorunko ON 163

2 Esimerkki: kolme eri elementtiä sisäkkäin <Element> <ELEMENT> <element> </element> </ELEMENT> </Element> Tyhjämerkin ([white space]) tulkinta vaihtelee eri kohdissa dokumenttia, esim. - tyhjämerkkien monikerrat jätetään huomiotta elementtien sisällä nimen ja attribuuttien välillä - merkitsee elementtien sisällä - 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 Esimerkki: <E A="123" B='abc'>Hello</E> RAKENTEISET DOKUMENTIT (kevät 2003 luentorunko ON 164

3 XML erottelee selvästi myös esim. merkistöihin, elementtien nimeämiseen ja attribuuttiarvoihin liittyviä termejä: - nimi ([name]) - tunnistemerkkijono ([name token]) [4] NameChar ::= Letter Digit '.' '-' '_' ':' CombiningChar Extender [5] Name ::= (Letter '_' ':') (NameChar)* [7] Nmtoken ::= (NameChar)+ Muut em. produktioissa 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) RAKENTEISET DOKUMENTIT (kevät 2003 luentorunko ON 165

4 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) RAKENTEISET DOKUMENTIT (kevät 2003 luentorunko ON 166

5 XML-dokumentin yleisrakenne XML-dokumentti jakautuu siis kahteen osaan: prologiin ja esiintymään [1] document ::= prolog element Misc* Prologi ([prolog]) - XML-versio, koodaus, erillisyys - dokumentin tyyppikuvaus 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 on "ripustettu informaatiota" RAKENTEISET DOKUMENTIT (kevät 2003 luentorunko ON 167

6 Esimerkki: dokumentin looginen rakenne PROLOGI ESIINTYMÄ <?xml version="1.0"?> <!DOCTYPE EXAMPLE SYSTEM "hellow.dtd"> <EXAMPLE> <TITLE>Hello World!</TITLE> <CONTENT> <TEXT>My very first XML-document</TEXT> <AUTHOR>Bill</AUTHOR> </CONTENT><DATE/> </EXAMPLE> Esimerkki vastaa rakennetta: EXAMPE TITLE CONTENT DATE Hello TEXT AUTHOR My Bill RAKENTEISET DOKUMENTIT (kevät 2003 luentorunko ON 168

7 Prologi XML-dokumentti alkaa aina dokumentin esittelyllä: [22] prolog ::= XMLDecl? Misc* (doctypedecl Misc*)? Prologi kuvaa ko. XML-dokumentin (läh. koodauksen) sekä esittelee mahdollisen dokumentin tyyppikuvauksen ([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 Prologi, jos sellainen dokumenttiin kirjoitetaan, alkaa aina XML-deklaraatiolla: [23] XMLDecl ::= '<?xml' VersionInfo EncodingDecl? SDDecl? S? '?>' Ensimmäinen XML-deklaraation kenttä kertoo käytetyn XML-version; toistaiseksi on olemassa vain versionumero 1.0: [24] VersionInfo ::= S 'version' Eq (' VersionNum ' " VersionNum ") RAKENTEISET DOKUMENTIT (kevät 2003 luentorunko ON 169

8 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, UTF-16 ja UCS-2) Esimerkki: <?xml version="1.0" encoding="utf-16"?> Lopuksi esitellään tieto siitä, selviääkö dokumentin validius "käsillä olevien tietojen perusteella" ([Standalone Document Declaration, SDD]) [32] SDDecl ::= S 'standalone' Eq (("'" ('yes' 'no') "'") ('"' ('yes' 'no') '"')) [ VC: Standalone Document Declaration ] XML-deklaraatiota seuraa prologissa mahdollinen dokumentin tyyppikuvaus (tähän palataan yksityiskohtaisesti seuraavassa luvussa) RAKENTEISET DOKUMENTIT (kevät 2003 luentorunko ON 170

9 "Ainoa todellinen syy" miksi XML-deklaraatio on valinnainen, on se että XMLdokumentteja voitaisiin käyttää joidenkin HTML- ja SGML-sovellusten yhteydessä (sekoittamatta näitä oudolla XML-koodeilla) - XML-prosessointiohjeiden syntaksi vastaava kuin SGML:ssä, mutta merkitystä ei (välttämättä) määritelty - XML-prosessointiohje on HTML:n näkökulmasta syntaksivirhe (vaikka esim. selain sen sivuuttaisikin) Vaikka prologin 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 prologin syntaksi näyttää ulkoisesti attribuuttien syntaksilta, ei se sitä ole (esim. koodien "version" ja "encoding" järjestystä ei saa vaihtaa") XML-deklaraatio ei itse asiassa "ole mitään muuta kuin" erikoinen XMLprosessorille tarkoitettu XML-prosessointiohje RAKENTEISET DOKUMENTIT (kevät 2003 luentorunko ON 171

10 Elementit XML-elementit ovat heti tuttuja HTML-kielitaitoisille: <TYPICAL ATTRIBUTE="VALUE">Content</TYPICAL> XML-erottelee selkeästi elementit joilla on sisältö tyhjistä elementeistä: <EMPTY STATUS="Feeling lonely!"/> 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 RAKENTEISET DOKUMENTIT (kevät 2003 luentorunko ON 172

11 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 "tavallisen" elementin alkutagikin: [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 STATUS="Not feeling lonely anymore!"></empty> Validien dokumenteissa elementtirakenne (minkätyyppiset elementit sallittuja ja millä rakenteella) voidaan määrätä dokumentin tyyppikuvauksessa XML-dokumentissa on aina vähintään yksi elementti: juurielementti RAKENTEISET DOKUMENTIT (kevät 2003 luentorunko ON 173

12 Attribuutit Myös XML-elementtien attribuuttien syntaksi on tuttua (muista tosin aina lainaus- tai heittomerkit!): <TYPICAL ATTRIBUTE="VALUE">Content</TYPICAL> Yhdellä elementillä voi olla monta eri attribuuttia, järjestyksellä ei ole väliä <_:second.example a="first" b='second'>content</_:second.example> 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 ] RAKENTEISET DOKUMENTIT (kevät 2003 luentorunko ON 174

13 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 "semanttinen" rajanveto kuitenkin helpottaa dokumenttien kirjoittamista ja lukemista "Yleensä" nyrkkisääntönä käytetään: - attribuutit ovat "abstrakteja" ominaisuuksia, joilla annetaan ominaisuuksia "konkreettisille" elementeille - 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-piirteiden" perustelemina - hierarkkisten rakenteiden määrittely onnistuu ainoastaan elementtirakenteiden muodossa RAKENTEISET DOKUMENTIT (kevät 2003 luentorunko ON 175

14 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ä RAKENTEISET DOKUMENTIT (kevät 2003 luentorunko ON 176

15 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 RAKENTEISET DOKUMENTIT (kevät 2003 luentorunko ON 177

16 "Yhden merkin mittaisia" (sisäisiä parsittuja) entiteettejä ei välttämättä "tarvita", 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]+ ';' Esimerkki: [ WFC: Legal Character ] Acme Etukäteen määritellyt entiteet ([predefined entities]) ovat: nimi merkki amp & lt < gt > apos ' quot " Esimerkki: <EXAMPLE>All HTML tags begin with <</EXAMPLE> RAKENTEISET DOKUMENTIT (kevät 2003 luentorunko ON 178

17 Kaikki muut entiteetit on määriteltävät (mahd. välillisesti) dokumentin prologissa (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 parsimiseen ja tähän liittyviin sääntöihin palataan myöhemmin) Entiteettien idea on siinä, että XML-prosessori välittää halutun tiedon XMLsovellukselle parsien 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), vrt. "ongelmallinen esimerkki": cout << "i=" << setw(3) << i << "units\n"; Ratkaisu: datalohkojen käyttö: RAKENTEISET DOKUMENTIT (kevät 2003 luentorunko ON 179

18 Datalohkot 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 ::= ']]>' Esimerkki: <![CDATA[ for (i=0; i<lim; ++i) if (buf[i]>def) fun(buf[i]); ]]> Datalohkoa luetaan sellaisenaan, eikä sen katsota sisältävän lainkaan muuta XML-merkkausta <![CDATA[ <p>this is <b>plain</b> text</p> - nothing more, nothing less ]]> RAKENTEISET DOKUMENTIT (kevät 2003 luentorunko ON 180

19 Vaaranpaikka piilee datalohkon päättävässä "]]>"-merkkijonossa Esimerkiksi tekstinpätkä if (buf[ind[i]]>lim) fun(i); pitäisi datalohkona koodata (esimerkiksi) muodossa <![CDATA[if (buf[ind[i]]]><!cdata[]>lim) fun(i);]]> XML perusteet Esimerkkitapauksessa kätevämpää lienee kuitenkin kirjoittaa entiteetin lt avulla koodi muodossa: if (buf[ind[i]]>lim) fun(i); Tilanne on ongelmallinen lähinnä XML-dokumentteja käsin kirjoittavalle - ohjelmallisesti koodaus on taas "helppo" piilottaa On syytä muistaa, että datalohkon sisältö todella on "parsimatonta merkkidataa" ([character data, CDATA]) - myöskään entiteetti- tai merkkiviittauksia ei voi käyttää (saattaa aiheuttaa ongelmia ASCII-editoreita käyttäville) Datalohkon voi kirjoittaa "minne tahansa missä merkkidatan kirjoittaminenkin on sallittua" (datalohko tulkitaan XML-merkkaukseksi) RAKENTEISET DOKUMENTIT (kevät 2003 luentorunko ON 181

20 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 identifioi koodin käsittelijän): Text and <?MY-FORMATTER FONT-FACE="16"?>big text 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 RAKENTEISET DOKUMENTIT (kevät 2003 luentorunko ON 182

21 Prosessointiohjauksen sijaan kannattaa yrittää suunnitella rakenteellisempia ratkaisuja ja dokumenttien kääntämistä 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. annettu DTD) - XML itse sitä vaatii "Yleensä käytettäviä" prosessointiohjeita ovatkin - XML-deklaraatio - XML-standardiperheeseen liittyvät prosessointiohjeet Kannattaa tosin huomata, että XML-deklaraatiota ei XML-kieliopissa johdeta produktiosta 16, vaan produktiosta 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) RAKENTEISET DOKUMENTIT (kevät 2003 luentorunko ON 183

22 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 2003 luentorunko ON 184

23 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 2003 luentorunko ON 185

24 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 2003 luentorunko ON 186

25 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 2003 luentorunko ON 187

26 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 2003 luentorunko ON 188

27 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 2003 luentorunko ON 189

28 Lark & Larval - Lark on ei-validoiva parseri, Larval myös validoi, molemmat kirjoitettu Javalla - ks. Xerces2 Java - hyvä Java-pohjainen jäsenninkirjasto - tulee myös nimiavaruuksia ja validointia XML-skeeman suhteen - ks. XML for Java - Javalla toteutettu hyvä validoiva XML-parseri - ks. TinyXML - Javalla toteutettu pieneen kokoon pyrkivä ei-validoiva XML-parseri - ks RAKENTEISET DOKUMENTIT (kevät 2003 luentorunko ON 190

29 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) - (laadukkaita XML-sovelluksia) - (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 2003 luentorunko ON 191

30 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 2003 luentorunko ON 192

31 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 2003 luentorunko ON 193

32 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 2003 luentorunko ON 194

33 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 2003 luentorunko ON 195

34 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 - IDEAlliance (International Digital Enterprise Alliance) (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 2003 luentorunko ON 196

35 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 2003 luentorunko ON 197

36 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 2003 luentorunko ON 198

37 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 2003 luentorunko ON 199

38 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 2003 luentorunko ON 200

39 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 2003 luentorunko ON 201

40 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 2003 luentorunko ON 202

41 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 2003 luentorunko ON 203

42 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 2003 luentorunko ON 204

43 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 2003 luentorunko ON 205

44 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 2003 luentorunko ON 206