5 Merkkaus: XML protokollana XML on siis ns. metakieli, joka käytännössä voidaan tulkita tavaksi merkitä ja tyypittää rakenteisia dokumentteja. XML on kuitenkin ennen kaikkea standardimuotoinen tietorakenne tiedonsiirtoon tietokoneohjelmien välillä. Tästä syystä XMLdokumenttiluokka on määriteltävä tietorakenteena tarkasti. Yksityiskohtainen määrittely pyrkii varmistamaan että XML-perustekniikan varaan rakennettujen sovellusten määrittely on vakaalla pohjalla.... XML 10010010010010010011 Me tutustumme asiaan koska asian XML-tekniikan ymmärtäminen "protokollan tasolla" tuo valmiudet arvioida eri prosessorien toimintaa ja esim. tulkita virhetilanteita ja eri XML-versioita (se toki on opettavaista myös sinänsä) 91
5.1 Välisoitto XML 1.0 (1.1) on melko matalan tason protokolla... - määritys on yleiskäyttöinen (...pinomainen määritys) - ei suoraan osoita sovelluksia - määrityksen on oltava teknisesti tarkka - näkyy kenties "vain välineiden läpi" 92
5.2 XML-dokumentin lukeminen XML 1.0 (1.1) -spesifikaatio jakaa dokumenttien käsittelyn kaksitasoiseksi prosessiksi, jossa XML-prosessori (processor) lukee XML-dokumentin ja välittää tämän jäsennettynä sovellukselle (application) - XML-prosessori osaa lukea ja jäsentää merkkauskieliopin mukaisia dokumentteja (sis. DTD-tyyppimääritys) - sovellus hyödyntää jäsennettyä tietoa prosessorin toimittaman informaation perusteella (yleensä jäsennyspuun perusteella) XML-prosessori (Puhekielessä "parseri") XMLdokumentti Ohjelmointirajapinta XML-sovellus Kohdesovellus (Koostuu useista komponenteista joista jotkin XML-sovelluksia) 93
5.3 Kyse on hyvin matalan tason määrittelystä XML 1.0 (1.1) on "protokollamainen" Erityisesti, XML 1.0 ei määrittele: - mihin sovellus käyttää XML-dokumentin tietoja - millainen ohjelmointirajapinta prosessorin ja sovelluksen välillä on (käytännössä yleensä kuitenkin "yleensä" SAX tai DOM) XML 1.0 (1.1) -spesifikaatio ei siis määrittele sovelluksen toimintaa käytännössä lainkaan (eikä siten XML-sovellusalueita) vaan keskittyy XML-prosessorin efektiivisen käyttäytymisen (erityisesti peruuttamattomien virheiden) kuvailuun Siispä... - XML:n varaan voidaan rakentaa mitä tahansa sovelluksia jotka hyödyntävät elementti- ja attribuuttirakenteista tietoa - Hyöty: tiedon matalan tason yhteensopivuus (merkkauskielioppi) 94
5.4 XML-dokumenttien merkkauksesta XML-dokumenttien merkkaus (markup) voi siis olla jotakin seuraavista: - prosessointiohje - dokumentin tyyppimäärittely - elementin alkutagi - elementin lopputagi - tyhjän elementin tagi - entiteettiviittaus - merkkiviittaus - kommentti - merkkidatalohko Kaikki muu tekstisisältö on merkkidataa Merkkaus tuli siis esiteltyä XHTML-dokumenttien esittelyn yhteydessä! - sama merkkauskielioppi on käytössä kaikissa XML-sovelluksissa: XHTML, SVG, DocBook, SOAP, RDF/XML,... ) e01 e00 e10 e11 ID IDREF 95
5.5 XML-dokumenttien jäsentäminen (1/2) Merkkauskieliopin täsmällisyydellä tavoitellaan tietenkin XML-dokumenttien ohjelmallisen käsittelyn yksikäsitteisyyttä (jäsennys onnistuu mekaanisesti) Dokumentin d.xml jäsennysyritys voi tuottaa seuraavat lopputulokset ok 1. d.xml sisältää merkkausvirheen d.xml ei ole XML-dokumentti 2. d.xml sisältää tyyppiesittelyn D muttei noudata sitä d.xml ei ole (tyyppi)validi XML-dokumentti #! (kuitenkin hyvin muodostettu XMLdokumentti jos kohta 1 läpäistiin) 3. d.xml sisältää tyyppiesittelyn D ja noudattaa sitä d.xml on validi XMLdokumenttia tyyppiä D 96
5.6... jäsentäminen (2/2) Huomautuksia - lopputulos 2 voi olla myös toivottu toisinaan dokumentin tyyppimäärittelyä käytetään esim. vain entiteettien määrittelyyn - jäsennin joka ei tunne sanastoa ei ymmärrä dokumentin kirjoittajan tai sovelluksen tavoitteitta jäsentimen raportoimat virheet eivät välttämättä ole kovin kuvaavia (vrt. rxp-esim: 1nimi, tiku&taku, jne.) - XML ei kerro miten "huonosti muodostettuja XML-dokumentteja" tulisi käsitellä, mikä on käytännössä pulma esim. editoreille Erilaisten XML-laajennusten myötä tulosten kirjo voi laajentua, erityisesti - noudattaako d.xml nimiavaruuksien kielioppia (joka lisää yhden kerroksen semantiikkaa XML-merkkauskieliopin tulkintaan) - noudattaako d.xml skeemaa D' (tms. globaaleja sanastoja) 97
5.7 XML -dokumenttiluokan määritelty XML-dokumentin rakenne on siis määriteltävä täsmällisesti, muuten sen mekaaninen lukeminen ja jäsentäminen ("parsiminen") ei onnistu Väärinymmärrysten välttämiseksi (ja teknisen toteutustyön pohjaksi), XML 1.0 (1.1) on määritelty formaalin kielen tavoin (tuotto)sääntöinä (XML 1.1; 83 kpl) joista kaikki ko. kielen sanat (nyt siis hyvin muodostetut XML-dokumentit) voidaan johtaa; vrt. esim. (XML 1.0) [1] document ::= prolog element Misc* /*...*/ [39] element ::= EmptyElemTag STag content ETag [ WFC: Element Type Match ] [ VC: Element Valid ] XML 1.1:n ero 1.0:aan on lähinnä määrittelytekninen (1.1 lähinnä huomioi alla olevan Unicode-standardin kehityksen ja lisää uuden rivinvaihtomerkin.) 98
5.8 Kontekstivapaa kielioppi ja EBNF Kielioppi on määritelty ohjelmointikielistä tuttua BNF-notaatiota mukaillen Extended Backus Naur Form (EBNF) esittää ns. kontekstivapaan kielen kieliopin G = (N, T, N 0, P): - tuottosäännöt (P), välisymbolit (N), loppusymbolit (T), operaattorit, merkkiluokat ja kertojat - ensimmäisenä esiteltävä tuottosääntö N 0 sovitaan kieliopin aksioomaksi josta kaikki ko. formaalin kielen sanat johdetaan - kieli määritellään siten että sanoille löytyy yksikäsitteinen jäsennyspuu - EBNF-muotoiset kieliopit ovat helppolukuisia mutta eivät kovin ilmaisuvoimaisia (täsmennettävä esim. sanallisin lisäyksin) T ::= '(' T O T ')' N N ::= [1234567890]+ O ::= '+' '-' '*' '/' Nyt EBNF on siis vain väline ns. hyvin muodostettujen XML-dokumenttien määrittelyyn se ei tietenkään "näy" dokumenteissa kuin välillisesti 99
5.9 EBNF-sääntöjen rakenne (1/3) Kieliopin määrittely perustuu nyt literaaliviittauksiin, sulkujen käyttöön, operaattoreihin ja kertojiin Merkki ja merkkijonoviittaukset: - #xn (N on halutun merkin indeksi) - [a-za-z],[#xn-#xm] (lueteltu merkkiluokan merkki) - [^abc], [^#xn#xm] (jokin muu merkki kuin lueteltu) - "string", 'string' (vakiomerkkijono) Sulkujen käyttö: - (lauseke) (lausekkeiden ryhmittely esim. kertojien vaikutusalueen asettamiseksi) 100
5.10 EBNF-sääntöjen rakenne (2/3) Operaattorit: - A B (B seuraa A:ta) - A B (A tai B muttei molemmat) - A - B (A muttei B:tä) Kertojat: - A? (A esiintyy kerran tai ei ollenkaan) - A+ (A esiintyy yhden tai useamman kerran) - A* (A esiintyy yhden tai useamman kerran tai ei ollenkaan) Loput säännöllisistä lausekkeista tutut operaattorit ja kertojat voidaan tarvittaessa konstruoida näistä metakielen tasolla, esim. "A{3,4}" on sama kuin "A A A A A A A" 101
5.11 EBNF-sääntöjen rakenne (3/3) Huom. XML-spesifikaatio esittelee lisäksi muutakin kielen määrittelyyn liittyvää notaatiota, erityisesti ns. rajoitteita (constraint): - /* */ (kommentti) - [ wfc: ] (well-formedness constraint) - [ vc: ] (validity constraint) Näitä tarvitaan teknisistä syistä, koska kontekstivapaa kielioppi (joka nyt siis kirjoitettu EBNF-notaatiota käyttäen) ei ole tarpeeksi vahva tiettyjen relaatioiden (järkevään esittämiseen), esim. - elementin alku- ja lopputagissa esiintyy sama nimi - elementin nimi on esitelty tyyppimäärittelyssä ja se esiintyy vanhemmassaan tämän tyyppiesittelyn mukaisesti 102
5.12 Merkitseviä asioita: nimet XML erottelee täsmällisesti merkistöihin, elementtien nimeämiseen ja attribuuttien arvoihin liittyviä termejä, näistä keskeisiä ovat: - 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. (XML 1.0 vs. 1.1) Nimiä käytetään tyypillisesti elementtien nimeämiseen, tunnistemerkkijonoja taas esim. attribuuttien arvoalueen rajaamiseen Huom. XML varaa nimien prefixarvot [xx][mm][ll] omaan käyttöönsä - esim. "xml-element" ei siis ole laillinen itse keksityn elementin nimi 103
5.13 XML-dokumentin yleisrakenne XML-dokumentti jakautuu siis kahteen osaan: esittelyyn ja esiintymään [1] document ::= prolog element Misc* Esittely (prolog) - XML-versionumero, koodaustapa, riippumattomuusesittely - dokumentin tyyppiesittely Esiintymä (instance, käytännössä juurielementti) - dokumentin sisältö (dokumentin juurientiteetti) mahdollisen tyyppikuvauksen rajoittaman loogisen rakenteen puitteissa 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" 104
5.14 XML-merkkauskieliopin määrittelystä (1/4) [22] prolog ::= XMLDecl? Misc* (doctypedecl Misc*)? [27] Misc ::= Comment PI S [23] XMLDecl ::= '<?xml' VersionInfo EncodingDecl? SDDecl? S? '?>' [24] VersionInfo ::= S 'version' Eq ("'" VersionNum "'" '"' VersionNum '"') [80] EncodingDecl ::= S 'encoding' Eq ('"' EncName '"' "'" EncName "'" ) [81] EncName ::= [A-Za-z] ([A-Za-z0-9._] '-')* /* Encoding name contains only Latin characters */ [32] SDDecl ::= S 'standalone' Eq (("'" ('yes' 'no') "'") ('"' ('yes' 'no') '"')) [ VC: Standalone Document Declaration ] Huomautuksia: - XML-esittely (tai julistus), dokumentin tyyppiesittely (tai julistus) - mikäli merkkikoodausta (encoding) ei ilmoiteta, oletetaan UTF-8 (prosessorit tukevan ainakin UTF-8 ja UTF-16, Suomessa ISO-8859-1 toisinaan tarpeen) 105
5.15 XML-merkkauskieliopin määrittelystä (2/4) Elementeillä on siis aina nimi (itse asiassa elementin tyypin nimi (generic identifier, GI)) ja saman nimen on tietenkin esiinnyttävä sekä elementin alkuettä lopputageissa: [39] element ::= EmptyElemTag STag content ETag [ WFC: Element Type Match ] [ VC: Element Valid ] [40] STag ::= '<' Name (S Attribute)* S? '>' [ WFC: Unique Att Spec ] [42] ETag ::= '</' Name S? '>' Tyhjän elementin tagi on hyvin samanlainen kuin elementin alkutagikin: [44] EmptyElemTag ::= '<' Name (S Attribute)* S? '/>' [ WFC: Unique Att Spec ] Tyhjän elementin saa siis kirjoittaa myös alku- ja lopputagien avulla (tällöin tagien väliin ei saa jäädä edes tyhjämerkkiä): 106
5.16 XML-merkkauskieliopin määrittelystä (3/4) Attribuuttien nimet määräytyvät kuten elementeillä, rakennekin on tuttu: [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 107
5.17 XML-merkkauskieliopin määrittelystä (4/4) Entiteetti- ja merkkiviittaukset määritelty odotetusti (lt, gt, amp, apos, quot): [67] Reference ::= EntityRef CharRef [68] EntityRef ::= '&' Name ';' [ WFC: Entity Declared ] [ VC: Entity Declared ] [ WFC: Parsed Entity ] [ WFC: No Recursion ] [66] CharRef ::= '&#' [0-9]+ ';' '&#x' [0-9a-fA-F]+ ';' [ WFC: Legal Character ] Merkkidatalohkot, prosessointiohjeet ja kommentit samoin... [18] CDSect ::= CDStart CData CDEnd [19] CDStart ::= '<![CDATA[' [20] CData ::= (Char* - (Char* ']]>' Char*)) [21] CDEnd ::= ']]>' [16] PI ::= '<?' PITarget (S (Char* - (Char* '?>' Char*)))? '?>' [17] PITarget ::= Name - (('X' 'x') ('M' 'm') ('L' 'l')) [15] Comment ::= '<!--' ((Char - '-') ('-' (Char - '-')))* '-->' 108
5.18 Tuttu esimerkki uudessa valossa ESITTELY ESIINTYMÄ <?xml version="1.0" encoding="iso-8859-1"?> <!DOCTYPE example SYSTEM "hellow.dtd"> <example> <title>hei maailma!</title> <content> <text>ensimmäinen XML-dokumentti</text> <author>nn</author> </content><date/> </example> example Elementtirakenne vs. "formaalin kielen sana" Huomioita: - esittelyosan tyyppi määrää title content "muotin" dokumentille - tyyppi saattaa pakottaa Hei text author attribuutteja joita ei ole merkattu Ensimmä NN esiintymäosaan - tyhjäsolmujen tulkinta tyypin mukaan (nyt ei merkitty kuvaan) date 109
5.19 XML-dokumentti on hyvin muodostettu XML-dokumentti on siis määritelmänsä ansiosta aina hyvin muodostettu (well-formed, WF); spesifikaation mukaan tekstidokumentti on (hyvin muodostettu) XML-dokumentti, jos 1) se voidaan kokonaisuutena johtaa XML-kieliopin documentaksioomasta, 2) se toteuttaa kaikki XML-kieliopin yhteydessä asetetut WFC-rajoitteet JA 3) jokainen tekstientiteetti, johon dokumentissa viitataan, on hyvin muodostettu XML-dokumentti (voi olla, ei ole pakko) lisäksi validi (valid), jos se esittelee tyyppinsä ja toteuttaa tyypin (VC-rajoitteet) - tyyppimäärittelystä voi siis olla hyötyä, vaikka validiuteen ei pyrittäisikään (entiteetit ja attribuuttien pakottaminen) Huomaa termit: esim. "väärin muodostettua XML-dokumenttia" ei siis ole olemassa (se on vain esim. "tekstidokumentti") 110
5.20 Huomautuksia jäsentimistä ja prosessoreista Käytännössä XML-dokumentin kirjoitusprosessissa tai tiedonsiirrossa saattaa tapahtua virhe, eikä lopputuloksena olekaan (WF) XML-dokumentti Tyypillinen XML-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) Erilaisia jäsentimiä on todella paljon (komentorivi, sulautettu, API, Web,...); kurssin kontekstissa hyviä ovat esim. Xerces ja RXP Yksiä ja samoja jäsentimiä kierrätetään eri ohjelmointiympäristöissä (esim. C-kielisen expatin käyttö PHP:ssä, Perlissä, Pythonissa jne.) XML-versioiden "1.0" ja "1.1" erot eivät yleensä merkittäviä, mutta todellisia 111