9 XML 1.0 - perusteet XML jakaa dokumenttien käsittelyn kaksitasoiseksi prosessiksi, jossa XMLprosessori ([processor]) lukee XML-tiedoston ja välittää tämän parsittuna 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" XML-dokumentin 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 EXA CON TEX AUT My Bill 0100100000 1010010110 1010100101 0110001010 1011001010 1001010010 XML-DOKUMENTTI XML-PROSESSORI SOVELLUS TULOS 73275 RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 152
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] ~"storage unit") - kaksi pääluokkaa: XML:n "tulkitsemat entiteetit" vs. XML:n "ulkopuoliset" entiteetit (sisältäen "parsittua" ja "parsimatonta" dataa) - "parsittu data" koostuu edelleen merkeistä ([character]) joka 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 2002) luentorunko ON 153
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 parsittu data on merkkidataa 73275 RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 154
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 on erottelee tunnisteet ja nimet isojen ja pienten kirjainten perusteella 73275 RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 155
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> 73275 RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 156
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) 73275 RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 157
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) 73275 RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 158
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" 73275 RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 159
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 73275 RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 160
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 ") 73275 RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 161
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) 73275 RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 162
"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 73275 RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 163
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 73275 RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 164
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 73275 RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 165
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 ] 73275 RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 166
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 73275 RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 167
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ä 73275 RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 168
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 2002) luentorunko ON 169
"Yhden merkin mittaisin" (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> 73275 RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 170
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ö: 73275 RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 171
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 ]]> 73275 RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 172
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 1.0 - 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) 73275 RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 173
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 73275 RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 174
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) 73275 RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 175