XML-standardiperhe 13 XML-standardiperhe Tähän mennessä lienee käynyt jo selväksi, mitä XML tarkoittaa: kyseessä on "vain" standardi tapa esittää puumaiseksi rakenteeksi jäsennettyä tietoa Perusmuodossaan XML 1.0 -spesifikaatio 1) kertoo, millainen XML-dokumenttien luokka on (Unicode-dokumenttien merkkaus) ja 2) tarjoaa keinon täsmällisesti kuvata tietyn loogisen elementtirakenteen omaavien dokumenttien luokkia XML-dokumenttien luokan sisällä (siis oleellisesti XML DTD-muodossa määrättävän skeeman muodossa) Mikäli XML-dokumentteja halutaan käyttää johonkin, tarvitaan tueksi muutakin XML 1.0 -spesifikaatio onkin vain osa laajempaa standardikokonaisuutta, ns. XML-standardiperhettä (joskin sen keskeisin osa) Standardiperhe tarjoaa lisää mahdollisuuksia XML-dokumenttien määrittelyyn ja käsittelyyn sekä tuo mukaan uutta semantiikkaa ja uusia ominaisuuksia Osa standardiperheestä vielä "työn alla" (keskeisin ydinosa melkein valmis) 73275 RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 323
XML-standardiperhe XML-standardiperheen ydinosat pääpiirteissään Extensible Markup Language (XML) 1.0 XML Schema XML Query XML Information Set XML Fragment Interchange Associating Style Sheets with XML documents Version 1.0 XSL Transformations (XSLT) Version 1.0 XSL Namespaces is XML XML Path Language (XPath) Version 1.0 XML Pointer Language (XPointer) Canonical XML Version 1.0 XML Base (XBase) XML Linking Language (XLink) Nuolet kuvaavat löyhän "määrittelyjärjestyksen" (ks. http://www.w3.org/xml/). 73275 RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 324
XML-standardiperhe W3C:n työnjaon näkökulmasta XML-standardiperhe jakautuu "arkkitehtuurin" ja "esitystavan" suhteen kutakuinkin seuraavasti: XML Path Language (XPath) Version 1.0 Namespaces is XML Associating Style Sheets with XML documents Version 1.0 CSS XSL SMIL HTML HTTP Extensible Markup Language (XML) 1.0 XSL Transformations (XSLT) Version 1.0 I18N DOM ARCHITECTURE DOMAIN DOCUMENT FORMATS DOMAIN Kolmas (3/5) tärkeä W3C:n toimialue on ns. Technology and Society Domain (sis. mm. ECommerce, RDF, P3P) - XML on keskeisessä roolissa tässäkin; ensisijaisesti tarjoamalla "yhteisen kielen" jolla "asioita" voidaan esittää XML-standardiperheen (ja muiden) spesifikaatioiden "tärkeysjärjestys" riippuu viime kädessä soveltajasta - toiselle linkitys on epäoleellista ja dataelementtien tietotyyppien määrittely tärkeää, toisille päinvastoin. Jollekulle XML on keino esittää dokumentteja verkossa, toiselle vain mekanismi, jonka varaan rakentaa kaupankäynnin standardeja ja tietorakenteita 73275 RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 325
XML-standardiperhe Yhteistä eri pyrkimyksille on se, että tieto siitä, miten asiat kannattaa tai pitää tehdä, tulee XML:n ulkopuolisesta maailmasta ja vaatii eri alojen "sisällöllistä asiantuntemusta" Mutta palataan taas kurssin ydinasiaan eli rakenteisiin dokumentteihin. Kokonaisuutena XML-standardiperheen ydinosa käsittelee lähinnä kolmentyyppisiä asioita: 1) dokumenttien koodaus ja looginen rakenne 2) linkitys 3) ulkoasu ja tyylimääritykset Ideoiden tasolla jako on jo tuttu. XML:ään liittyvien standardien ytimen muodostavat tästä näkökulmasta 1) XML 1.0 2) XLink 3) XSL Kuten aikaisemmin huomattiin, standardiperhe on käytännössä jakautunut useiksi spesifikaatioiksi, joiden varassa "pidemmälle menevät" spesifikaatiot sitten toimivat 73275 RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 326
"Ydinspesifikaatioiden" tärkeimmät osat ovat Namespaces ja XPath XML-standardiperhe - Namespaces tarjoaa ratkaisun samannimisten mutta eri merkityksen omaavien elementtien ongelmaan (esim. yhdessä XML-dokumentissa PARA tarkoittaa "kappaletta" ja toisessa "parametria") - XPath tarjoaa keinon puurakenteisiin viittaamiseen ja osien valitsemiseen Dokumenttien syntaksin, linkityksen ja ulkoasun lisäksi standardiperhe ennen kaikkea tarjoaa tiedon esittämiseen ja käsittelyyn lisää "syvyyttä": - skeemojen yksityiskohtaisempi määrittely (XML Schema) - oleellisesti samojen dokumenttien (loogisten dokumenttiluokkien) tunnistaminen (Canonical XML) - dokumenttien metatiedon ja osien käsittely sekä tiedon hakeminen (XML Information Set, Fragment Interchange ja Query) On erittäin tärkeätä huomata, että yksi ja sama XML-syntaksi toimii useiden spesifikaatioiden määrittelemien dokumenttien perustana - ideana on, että eri spesifikaatiot oleellisesti antavat "tietyntyyppisten" XML-dokumenttien semantiikan (ja sitovat sen 1-käsitteisesti Namespacen avulla) 73275 RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 327
XML-standardiperhe XML 1.0:n vankka tuntemus auttaa ymmärtämään myös muita XML:ään liittyviä standardeja (tai oikeastaan vasta mahdollistaa tämän). Samat perusideat toistuvat muuallakin - rakenteisten dokumenttien perusideat - motivaatio ja tavoitteet kehitystyölle ja määritelmien "sanamuodoille" - dokumenttien koodaus- ja merkkauskäytäntö - määrittelyn menetelmät: EBNF-notaatio, DTDt, XML-standardiperhe on kokonaisuutena niin merkittävä (ja pelkkä XML 1.0 tavallaan "triviaali"), että toisinaan XML:stä puhuttaessa tarkoitetaankin juuri koko XML-standardiperhettä (tai sen asiayhteydessä rajattua ydinosaa) Käytännössä "tiedettävän määrä" on kuitenkin vielä edellä kuvattuakin suurempi, koska XML-standardit viittaavat myös useisiin muihin W3C:n standardeihin (CSS, URI, DOM, RDF, ) - ja joskus myös "toisten" standardeihin (DocBook, Java, ) Koska standardeja ja tiedettävää on siis varsin paljon (ja tulee koko ajan lisää), kannattaa tutustua XML 1.0:aan ja standardiperheen ytimeen huolella ja hankkia hyvä "sisälukutaito" uuden omaksumiselle (omassa työssä sovellettavaksi, kun opiskelee seuraavaa uutta asiaa ) 73275 RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 328
14 Namespaces Huomautus: Otsikon voisi kuvaavammin kirjoittaa muodossa "structdoc:section". Syy selviää piakkoin Merkkauksen ideana on helpottaa tiedon ja metatiedon erottelua tarjoamalla dokumenteille selkeä rakenne Esimerkki: kun teksti Leevi and the Leavings: Mitä kuuluu, Marja-Leena? Teuvo, maanteiden kuningas Mieletön Melinda kirjoitetaan muotoon (ja koodataan vähän lisätietoa) <RECORD AUTHOR="Leevi and the Leavings"> <ITEM LEN="3.42">Mitä kuuluu, Marja-Leena?</ITEM> <ITEM LEN="4.09">Teuvo, maanteiden kuningas</item> <ITEM LEN="3.14">Mieletön Melinda</ITEM> </RECORD> "huomataan heti", mitä kirjoittaja ajaa takaa ja tarkoittaa. Vai huomataanko? 73275 RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 329
Ongelmaa syntyy, kun "samoilla" elementtien nimillä on useita järkeviä tulkintoja. Asiaa on hyvin vaikea välttää etukäteen Esimerkki: entäpä jos meillä olisi annettuna vielä toinenkin dokumentti: <RECORD AUTHOR="Matti Nykänen"> <ITEM LEN="80">pieni mäki</item> <ITEM LEN="245">lentomäki</ITEM> </RECORD> Namespaces Mitäs nämä sitten tarkoittavat? Ilmeisestikin eri asioita kuin edellä, mutta millä se huomataan? Entäpä jos elementin ITEM sisältö olisi vielä erilainen? On suuri kiusaus sanoa, että dokumentit erotetaan niiden sisältämän tiedon perusteella. Tietokoneelle tehtävä on kuitenkin auttamattomasti liian vaikea, koska ihminenkään ei erottelua aina pysty tekemään Esimerkki: entäpä jos dokumentit pitäisi vielä syystä tai toisesta yhdistää? Olkoon siis dokumentti, joka listaa laulaja Matti Nykäsen kappaleita ja mäkihyppyennätyksiä. Mistä elementit ITEM nyt erotetaan? <RECORD AUTHOR="Matti Nykänen"> <ITEM LEN="80">pieni mäki</item> <ITEM LEN="3.42">Yllätysten yö</item> </RECORD> 73275 RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 330
Kurssin alkupuolella samantyyppiseen ongelmaan törmättiin HTMLelementtien semantiikan (ulkoasun näkökulmasta) kanssa: on tilanteita, jossa elementti P tarkoittaa yhtä ja toisaalla toista. Ongelma ratkaistiin CSSattribuutin CLASS avulla seuraavasti: <P CLASS="std">Tämä on tavallinen tekstikappale</p> <P CLASS="add">Tämä tekstikappale kertoo "lisätietoja"</p> XML ratkaisi kömpelön CLASS-attribuuttien käytön tarjoamalla mahdollisuuden omannimisten (-tyyppisten) elementtien määrittelyyn Edellä ongelma olisi siis voitu ratkaista XML:n avulla vaikkapa muodossa <stdp>tämä on tavallinen tekstikappale</stdp> <addp>tämä on erikoinen tekstikappale</addp> ts. kirjoittamalla "kaikki" tieto suoraan elementin nimeen. Tämä ei kuitenkaan poista ongelmaa, jossa eri kirjoittajat keksivät samannimisiä elementtejä (ja yhdistelevät elementtirakenteitaan) Edellä artisti-mäkihyppääjän tapauksessa ongelma voitaisiin yrittää ratkaista järkevästi keksimällä "tarpeeksi kuvaavia" elementin nimiä, esim. tyyliin <SKIJUMPITEM LEN="80">pieni mäki</skijumpitem> <MUSICITEM LEN="3.42">Yllätysten yö</musicitem> 73275 RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 331
Periaatteessa ratkaisu on hyvä, mutta jäljelle jää vielä hankalia ongelmia: - täsmällisistä elementtien nimistä tulee helposti mahdottoman pitkiä (SKIJUMPITEMFOROSSINYKANENSAPPLICATIONATTUTINFINLAND) - ja silti vaarana on, että joku toinen ottaa käyttöön juuri saman elementin eri merkityksessä, koska nimeämiskäytäntöä ei hallinnoida keskitetysti XML Namespaces ("nimiavaruudet") periaatteessa ratkaisee em. ongelmat: 1) elementtien ja attribuuttien nimet nimetään yksikäsitteisesti mv. pitkien tunnistemerkkijonojen avulla (jotka juuri määrittävät nimiavaruuden), 2) nimiavaruudet annetaan erityisen attribuutin avulla, jonka tulkinta on kiinteä (xmlns), 3) pitkien nimien aiheuttamat hankaluudet pyritään minimoimaan ottamalla käyttöön nimille lyhennysmerkinnät (prefiksit) ja 4) tunnistemerkkijonojen "myöntäminen" käyttöön sidotaan olemassa olevaan yksikäsitteiseen tiedon nimeämiskäytäntöön (URI) XML Namespaces tarjoaa oleellisesti mahdollisuuden kiinnittää elementtien ja attribuuttien nimiin yksikäsitteisen nimilapun, jonka avulla kaikkien maailman elementtien ja attribuuttien nimien erottaminen toisistaan on mahdollista 73275 RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 332
Esimerkki: XML-nimiavaruuksien käytön avulla ITEM-elementtien erottamisen ongelma ratkeaa nyt esim. muodossa (kun nimiavaruuksien merkitys sovitaan) <RECORD AUTHOR="Matti Nykänen"> <ITEM LEN="80" xmlns="http://matriisi.ee.tut.fi/~onykane/skijump/"> pieni mäki </ITEM> <ITEM LEN="3.42" xmlns="http://matriisi.ee.tut.fi/~onykane/music/"> Yllätysten yö </ITEM> </RECORD> Esimerkki: samaan päästään myös "kvalifioitujen" elementtien prefiksikoodauksen avulla. Tällöin dokumentti tulee esim. muotoon <RECORD AUTHOR="Matti Nykänen" xmlns:ski="http://matriisi.ee.tut.fi/~onykane/skijump/" xmlns:music="http://matriisi.ee.tut.fi/~onykane/music/"> <ski:item LEN="80"> pieni mäki </ski:item> <music:item LEN="3.42" Yllätysten yö </music:item> </RECORD> Jos tarkkoja ollaan, tilanne attribuuttien suhteen jää Namespacesin näkökulmasta tosin vieläkin epäselväksi (aiheeseen palataan pian) 73275 RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 333
Peruskäsitteitä XML Namespace tarjoaa siis keinon nimetä kokoelman elementtien ja attribuuttien nimiä jossakin sovelluksessa (dokumentissa). Näitä nimiä kutsutaan ko. sovelluksen sanastoksi ([vocabulary]) Esimerkki: seuraavan dokumentin sanasto on (EXAMPLE, TYPE, STRONG); samannimisten elementtien ja attribuuttien nimet osataan erottaa toisistaan <EXAMPLE TYPE="simple">this is <STRONG/> text</example> Ei-toivottua tilannetta, jossa kahden eri sanaston samoja sanoja käytetään eri merkityksessä kutsutaan törmäykseksi ([collision]) (edellä ITEMit törmäsivät) Spesifikaation "Namespaces in XML" (Namespaces) perusta käsittelee juuri sanastojen nimeämiskäytäntöä tavoitteena törmäysten välttäminen (ks. http://www.w3.org/tr/1999/rec-xml-names-19990114/) XML-nimiavaruus ([XML Namespace]) on kokoelma sovelluksen elementtien ja attribuuttien niminä käytettäviä nimimerkkijonoja, joka identifioidaan URImerkkijonon avulla Nimiavaruuden nimi on sitä vastaavan URI-merkkijonon arvo 73275 RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 334
Esimerkki: asetetaan (oletus)nimiavaruus, jonka nimi on "http://matriisi.ee.tut.fi/" <EXAMPLE xmlns="http://matriisi.ee.tut.fi/"></example> Viittaukset nimiavaruuksiin ovat identtisiä mikäli niitä vastaavien nimiavaruuksien nimet ovat tavallisina merkkijonoina samoja URI-merkkijonoilla ei nimiavaruuksien niminä ole nimilappuna toimivan merkkijonon lisäksi muuta tulkintaa (ts. niiden ei esim. ole pakko viitata oikeisiin tiedostoihin verkossa, tms.) Esimerkki: seuraavat merkkijonot viittaavat WWW-selainten "yleisen" URLsemantiikan mukaisesti samaan HTML-dokumenttiin, mutta nimiavaruuksien yhteydessä tarkoittavat eri nimiavaruuksien nimiä matriisi.ee.tut.fi/~onykane/courses/ http://matriisi.ee.tut.fi/~onykane/courses/ Nimiavaruuksien sisältämät nimet esiintyvät XML-dokumenteissa jommassakummassa kahdesta perusmuodostaan: - kvalifioituna nimenä ([qualified name]) tai - lokaalina (kvalifioimattomana) nimenä (koostuen vain nimen lokaaliosasta [local name]) 73275 RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 335
Kvalifioitu nimi koostuu kahdesta kaksoispisteellä ":" erotetusta osasta: nimiavaruuden prefiksistä ja lokaaliosasta ([namespace prefix], [local part]) Esimerkki: kvalifioitu nimi elementin nimenä <ex:element>don't let the colon fool you!</ex:element> Kvalifioidussa nimessä on aina täsmälleen yksi kaksoispiste ja se on ylläkuvatussa roolissa Huomaa, että XML 1.0 -spesifikaation näkökulmasta kvalifioitu nimi on "vain XML-nimi" - ts. kaksoispisteellä ei XML 1.0:n näkökulmasta ole erityistä tulkintaa (joskaan kaksoispisteitä ei elementtien ja attribuuttien nimissä siis kannata käyttää, johtuen kaksoispisteen tulkinnasta nimiavaruuksien yhteydessä) Kvalifioidun nimen prefiksi, joka assosioidaan halutun URI-merkkijonon kanssa, valitsee nimiavaruuden Lokaali (kvalifioimaton) nimi sidotaan oletusnimiavaruuteen, perii vanhempansa nimiavaruuden tai ei kuulu mihinkään nimiavaruuteen Kvalifioidun nimen prefiksin (esim. ex) kiinnittäminen halutun nimiavaruuden kanssa suoritetaan XML-attribuutin avulla (esim. xmlsn:ex="nimiavaruuden nimi") 73275 RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 336
Nimiavaruusdeklaraation perusteet: oletusnimiavaruudet Nimiavaruusdeklaraatio ([namespace declaration]) suoritetaan XMLdokumentin esiintymäosassa joko xmlns-nimisen attribuutin avulla, tai attribuutin, jonka prefiksi on "xmlns:", avulla. Nämä attribuutit voidaan tuottaa joko suoraan tai välillisesti (kuten mitkä tahansa muutkin XML-attribuutit) Yksinkertaisimmillaan nimiavaruusdeklaraatio annetaan juuri "paljaan" xmlnsattribuutin avulla. Tällöin asetetaan oletusnimiavaruus ([default namespace]) Esimerkki: valitaan nimiavaruus "http://matriisi.ee.tut.fi/~onykane/rakdok/lk_ex327" <EX xmlns="http://matriisi.ee.tut.fi/~onykane/rakdok/lk_ex327"> <CONTENT ATTR="no default namespace for us attributes"> Element content inherits EX's namespace </CONTENT> </EX> Määrittelyn idea on edellä se, että attribuutti xmlns kertoo sen nimiavaruuden nimen, jonka sanastoon määrittelyn vaikutusalueella (määrittelyalueella [scope]) sijaitsevat elementit kuuluvat. Vaikutusalue selviää nimiavaruuden yksikäsitteisten periytymissääntöjen perusteella 73275 RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 337
Koska nimiavaruuksien nimet ovat universaaleja (mikä siis on koko homman tavoite), ei pitäisi jäädä epäselvyyttä siitä, mitä elementit EX ja CONTENT "tarkoittavat" (ei törmäyksiä) Namespaces ei kerro miten elementtien semantiikka tulee antaa, vaan osoittaa ainoastaan menetelmän jolla elementeille voidaan valita universaalit nimet. Dokumentin sanaston semantiikka voidaan kertoa esim. sanallisesti ja esimerkkien avulla URI-viittauksen päässä olevassa HTML-dokumentissa, mutta spesifikaatio ei tätä edellytä Edellinen yksinkertainen esimerkki on vain erikoistapaus nimiavaruuksien määrittelystä. Kirjataan esimerkistä joitain huomioita: - sanaston sanojen EX, CONTENT ja ATTR nimet ovat lokaaleja nimiä (ei kvalifioituja) - attribuutti xmlns asettaa oletusnimiavaruuden arvoksi "http://mat ". Nimiavaruus asetetaan elementin EX ja sen lapsielementtien nimiavaruudeksi - koska elementti CONTENT on EX:n sisällä elementti CONTENT perii oletusnimiavaruuden (mutta attribuutti ATTR ei, johtuen sovituista perintäsäännöistä) 73275 RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 338
Määrittely Namespaces-spesifikaatio määrittelee nimiavaruuksien käytön syntaktisen rakenteen EBNF-produktioiden muodossa (vrt. XML) Nimiavaruuksien spesifikaatio esittelee 18 produktioita, jotka yhdistetään XML 1.0 -spesifikaation kanssa Osa Namespaces-spesifikaation produktioista "jatkuu XML-spesifikaation produktioina" (joita ei esitellä uudelleen). Osa Namespaces-produktioista taas "päällekirjoittaa" XML 1.0 -produktioita, joten Namespaces tavallaan siis määrittää XML 1.0:n uudelleen! Ao. otteen numerointi seuraa spesifikaatiota [1] NSAttName ::= PrefixedAttName DefaultAttName [2] PrefixedAttName ::= 'xmlns:' NCName [ NSC: Leading "XML" ] [3] DefaultAttName ::= 'xmlns' [4] NCName ::= (Letter '_') (NCNameChar)* /* An XML Name, minus the ":" */ [5] NCNameChar ::= Letter Digit '.' '-' '_' CombiningChar Extender 73275 RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 339
Nimiavaruusdeklaraatio annetaan siis tehtävään varatun NSAttNamemuotoisen attribuutin avulla Namespaces Produktiota PrefixedAttName ([2]) vastaavan attribuutin nimen osa NCName assosioidaan attribuutin arvon saatavan nimiavaruuden nimeä vastaavan nimiavaruuden prefiksiksi ([namespace prefix]) (attribuutin arvo ei tällöin saa olla tyhjä) Nimiavaruuden nimen tulee olla URI-syntaksin mukainen merkkijono (Uniform Resource Identifier ks. esim. http://info.internet.isi.edu/innotes/rfc/files/rfc2396.txt). Nimi on siis pelkkä syntaktinen nimilappu jolla ei ole URIn semantiikkaa (siis ei tarvitse olla, joskin voi olla) Oletusnimiavaruuksien käyttäminen on siis vain yksi tapa, jolla sitoa elementin nimiavaruus. Toinen (monipuolisempi) tapa on tehdä se juuri nimiavaruuksien prefiksien avulla Esimerkki: valitaan nimiavaruus "http://matriisi.ee.tut.fi/" ja sille prefiksi ex <ex:example xmlns:ex="http://matriisi.ee.tut.fi/"> <ex:content ex:attr="ex namespace for me"> ex namespace for me </ex:content> </ex:example> 73275 RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 340
Huomaa, että nimiavaruus ex otetaan käyttöön vasta kvalifioitujen elementtien ja attribuuttien nimien muodossa (xmlns:ex-deklaraatio vain esittelee sen) Nimiavaruuden prefiksiä ei ole pakko esitellä siinä elementissä, jossa prefiksiä käytetään, vaan määrittely voidaan antaa myös elementin vanhemmassa Esimerkki: sama esimerkki toisessa muodossa <edi:x xmlns:edi='http://ecommerce.org/schema'> <!-- the "edi" prefix is bound to http://ecommerce.org/schema for the "x" element and contents --> <edi:sub> I'll use namespace whose prefix is edi explicitly! </edi:sub> <sub> I use the same namespace (but instead of declaring it, I inherit it from the element edi:x) </sub> <edi:sub xmlns:edi="http://www/foo"> I overwrite the previous namespace and use my own namespace (and so will my children) </edi:sub> </edi:x> 73275 RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 341
Kvalifioitujen (prefiksi) nimien käyttäminen mahdollistaa erityisesti: Namespaces - nimiavaruudet attribuuteille (attribuuttien nimiavaruus määrätään aina prefiksien avulla) - merkintöjen sieventämisen, jos eri nimiavaruuksiin viitataan "vuorotellen" Attribuutit, joilla ei ole nimiavaruuden prefiksiä eivät kuulu mihinkään nimiavaruuteen. Jos attribuutille halutaan siis määrätä nimiavaruus, pitää se aina tehdä kvalifioidun nimen avulla Esimerkki: sidotaan attribuutin xlink:type nimiavaruus <x xmlns:xlink='http://www.w3.org/xml/xlink/0.9'> No namespace for x, we only declare xlink namespace <sub xlink:type="simple">no namespace for sub</sub> </x> Nimiavaruusdeklaraatio annetaan aina XML-dokumentin esiintymäosassa (DTD:ssä deklaraatio voidaan tuottaa välillisesti antamalla attribuuteille oletusarvoja) Produktiota DefaultAttName ([3]) vastaavan attribuutin arvo valitsee oletusnimiavaruuden ([default namespace]). Tällöin attribuutin arvo voi olla myös tyhjä (mikä tarkoittaa sitä, että nimiavaruutta ei valita lainkaan) 73275 RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 342
Periytyminen, määrittelyalue ja attribuutit Nimiavaruus periytyy kvalifioimattomille elementeille Esimerkki: valitaan oletusnimiavaruudeksi "http://matriisi.ee.tut.fi/" <EXAMPLE xmlns="http://matriisi.ee.tut.fi/"> My namespace is the default stated above <CONTENT ATTR="no default namespaces for us attributes"> I inherit EXAMPLE's (default) namespace <SUB xmlns=""> I don't want any namespace! <ITEM>...and I don't inherit any </ITEM> </SUB> </CONTENT> <ITEM>...I inherit EXAMPLE's (default) namespace </ITEM> </EXAMPLE> Kvalifioimattomien elementtien tapauksessa periytyminen on siis suoraviivaista: elementti perii vanhempansa nimiavaruuden ellei toisin mainita 73275 RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 343
Jos elementtejä kvalifioidaan, periytyminen on hieman monimutkaisempaa Esimerkki: valitaan oletusnimiavaruudeksi "http://matriisi.ee.tut.fi/" <EXAMPLE xmlns="http://author/default/" xmlns:foo="http://author/foo/"> xmlns:zap="http://author/zap/"> My namespace is the default stated above <foo:content attr="no namespace for me"> I use foo namespace <SUB xmlns=""> I don't use any namespace! </SUB> <SUB zap:attr="my namespace is zap"> I inherit default namespace from EXAMPLE </SUB> </foo:content> <ITEM foo:attr="my namespace is foo"> I inherit the default namespace from EXAMPLE </ITEM> </EXAMPLE> Kuten edellisessä esimerkissä, nimiavaruuksien nimet ja niitä vastaavat kvalifioitujen nimien prefiksit yleensä samaistetaan kielenkäytössä 73275 RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 344
Elementin nimiavaruus määräytyy siis joko tämän kvalifioidun nimen, oletusnimiavaruuden tai jälkimmäisen perinnän perusteella Esimerkki: elementin ex nimiavaruuden asettaminen kahdella eri tavalla <!-- CASE 1: declaring default namespace --> <ex xmlns="http://example/ex"> </ex> Namespaces <!-- CASE 2: declaring explicit namespace prefix and using it --> <myns:ex xmlns:myns="http://example/ex"> </myns:ex> Nimiavaruus periytyy aina kvalifioimattomalle elementille tämän vanhemmilta (vanhemman [perimä] oletusnimiavaruus) ellei elementti itse aseta omaa oletusnimiavaruutta. Kvalifioitu elementti ei koskaan peri nimiavaruutta, vaan prefiksi kertoo sen. Attribuuteilla perintää ei koskaan tapahdu, vaan attribuutin nimiavaruus määräytyy aina kvalifioidun nimen perusteella Tyhjän oletusnimiavaruuden antamisella nimiavaruuksien vaikutus voidaan siis "kytkeä pois päältä" Oletusnimiavaruuksien avulla elementtejä voidaan sitoa nimiavaruuksiin ilman, että niiden nimet täytyy kirjoittaa kvalifioidussa muodossa (tästä on suurta hyötyä esim. DTD:n määrittelyn näkökulmasta) 73275 RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 345
Nimiavaruudet ja XML DTD: luvassa käytännön ongelmia Toistaiseksi nimiavaruuksien käsittelyn yhteydessä on puhuttu XMLdokumenteista mutta ei valideista XML-dokumenteista (ts. dokumenteista, jotka sisältävät DOCTYPE-deklaraation ja noudattavat sitä) Miten nimiavaruudet sitten pitää ottaa huomioon validien XML-dokumenttien suhteen? Vastaus: teoriassa ei mitenkään - kaikki XML DTD:stä tähän mennessä sanottu on sellaisenaan voimassa myös nimiavaruuksien suhteen! Tämä tarkoittaa seuraavaa: - nimiavaruudet ja DTD eivät yleensä ole käyttökelpoisia yhdessä - kvalifioidut nimet ovat XML 1.0-spesifikaation näkökulmasta tavallisia nimiä (nimiavaruuden ilmoittava prefiksi ja kaksoispiste on osa nimeä) - attribuutti xmlns on niinikään tavallinen attribuutti muiden joukossa (jonka järkevä tyyppi on yleensä CDATA) Seuraukset dokumenttien tyyppideklaraatioiden näkökulmasta ovat selkeitä, mutta työläitä - jos nimiavaruuksia hyödyntävä dokumentti halutaan määrittää validiksi, pitää kaikki sallitut prefiksikombinaatiot esitellä DTD:ssä 73275 RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 346
Esimerkki: seuraava pieni validi XML-dokumentti havainnollistaa nimiavaruuksien ja XML DTD:n välistä suhdetta <?xml version="1.0"?> <!DOCTYPE mydoc [ <!ELEMENT mydoc (foo:ex,zap:ex)> <!ELEMENT foo:ex (#PCDATA zap:ex ex)*> <!ELEMENT zap:ex (#PCDATA)> <!ELEMENT ex (#PCDATA)> <!ATTLIST mydoc xmlns:zap CDATA #IMPLIED xmlns:foo CDATA #IMPLIED> ]> <mydoc <!ATTLIST ex xmlns CDATA #IMPLIED> xmlns:zap="http://author/zap" xmlns:foo="http://author/foo"> <foo:ex> My namespace is foo <zap:ex>my namespace is zap</zap:ex> <ex>i inherit foo namespace</ex> <ex xmlns="http://author/other"> I declare my own default namespace </ex> <ex xmlns="">i don't use any namespace</ex> </foo:ex> <zap:ex>my namespace is zap</zap:ex> </mydoc> Namespaces 73275 RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 347
On kuitenkin erittäin todennäköistä, että tietty prefiksi halutaan aina sitoa tietyn nimiseen nimiavaruuteen. Tällöin prefiksin määräävä attribuuttilistadeklaraatio on ilmeisen järkevää kiinnittää valmiiksi jo DTD:ssä Esimerkki: edellisessä esimerkissä olisi todennäköisesti perusteltua asettaa <!ATTLIST mydoc xmlns:zap xmlns:foo CDATA #FIXED "http://author/zap" CDATA #FIXED "http://author/foo"> Ilmeisesti tilanne on DTD:n näkökulmasta paljon yksinkertaisempi jos tyydytään käyttämään pelkkiä oletusnimiavaruusdeklaraatioita - tällöin hintana on kuitenkin se, että XML-prosessorin mahdollisuudet syntaktisten virheiden löytämiseen heikkenevät entisestään (edellä sentään nimien ja nimiavaruuksien prefiksideklaraatioiden väärinkäyttö huomattiin dokumenttia validoitaessa) Vakioarvojen pakottaminen on itse asiassa niin järkevää, että monet Namespaces-yhteensopivat XML-parserit tätä (vastoin Namespacesspesifikaatiota) vaativatkin (esim. IE5 ja XML Spy) Tilanne on käytännössä todella ongelmallinen; mikäli sovelluksissa tarvitaan monipuolisesti nimiavaruuksia, on järkevämpää määritellä dokumenttiluokan looginen rakenne skeeman avulla (XML Schema) 73275 RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 348
Nimiavaruuksien käyttö edellyttää tietenkin että XML-prosessori nimiavaruuksien semantiikan osaa tulkita Namespaces On erittäin tärkeätä huomata, että edellisissä esimerkeissä XML 1.0- spesifikaation näkökulmasta Namespaces-käsitteet kuuluvat XML 1.0:n ulkopuoliseen maailmaan (esim. "foo:ex" on vain elementin nimi siinä missä "mydoc" on elementin nimi) Erityisesti tämä tarkoittaa sitä, että joissain tilanteissa Namespacesin näkökulmasta kaksi eri XML 1.0:n nimeä "tarkoittaa" samaa asiaa (tarkoittavat saman sanaston sanaa) Esimerkki: eri nimet mutta "uniikin sanaston samat sanat" <foo:ex xmlns:foo="http://author/concept"/> <zap:ex xmlns:zap="http://author/concept"/> Attribuuttien nimien suhteen tämä tarkoittaa sitä, että "XML-syntaksia" on sanastojen näkökulmasta mahdollista rikkoa ilman että XML 1.0-prosessori tajuaa asiaa 73275 RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 349
Esimerkki: seuraava on Namespaces-virhe (sama attribuutti ei saa esiintyä alkutagissa kuin kerran) <foo:ex xmlns:foo="http://author/concept"/ xmlns:zap="http://author/concept"/ foo:attr="setting a value" zap:attr="i'm an illegal attribute!"/> XML-dokumenttien prosessoinnin näkökulmasta Namespaces tuo muassaan vielä lisää vaikeuksia: ei-validoiva XML-parseri kun ei välttämättä "näe" aina koko XML-dokumenttia (lähinnä parsittavien ulkoisten entiteettien tapaus ja attribuuteille annettavat oletusarvot DTD:ssä) - tällöin voi käydä niin, että esim. prefiksideklaraatio jää huomiotta ja tuloksena on laiton kvalifioitu nimi Namespaces-yhteensopivat parserit luonnollisestikin yrittävät tarjota ratkaisua ongelmaan (esim. siten, että jokainen prosessointi on validoiva) Esitellään lopuksi Namespaces-tuottosäännöt. Seuraavat produktiot täsmentävät aikaisemmin esiteltyjä käsitteitä ("kvalifioitu nimi") [6] QName ::= (Prefix ':')? LocalPart [7] Prefix ::= NCName [8] LocalPart ::= NCName 73275 RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 350
Kvalifioituja nimiä käytetään Namespaces-merkkausdeklaraatiossa kuten "tavallisessakin" DTD:ssä (huomaa päällekkäisyys XML 1.0:n kanssa) [13] doctypedecl ::= '<!DOCTYPE' S QName (S ExternalID)? S? ('[' (markupdecl PEReference S)* ']' S?)? '>' [14] elementdecl ::= '<!ELEMENT' S QName S contentspec S? '>' [15] cp ::= (QName choice seq) ('?' '*' '+')? [16] Mixed ::= '(' S? '#PCDATA' (S? ' ' S? QName)* S? ')*' '(' S? '#PCDATA' S? ')' [17] AttlistDecl ::= '<!ATTLIST' S QName AttDef* S? '>' [18] AttDef ::= S (QName NSAttName) S AttType S DefaultDecl Kvalifioidut nimet vaikuttavat luonnollisesti merkkauksen kirjoittamiseenkin [9] STag ::= '<' QName (S Attribute)* S? '>' [ NSC: Prefix Declared ] [10] ETag ::= '</' QName S? '>' [ NSC: Prefix Declared ] [11] EmptyElemTag ::= '<' QName (S Attribute)* S? '/>' [ NSC: Prefix Declared ] [12] Attribute ::= NSAttName Eq AttValue QName Eq AttValue [ NSC: Prefix Declared ] 73275 RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 351
Huomautuksia Namespaces on todella keskeinen spesifikaatio koko XML-stdperheessä: lähes kaikki muu standardoitu rakentuu juuri uniikkien sanastojen idean varaan Ei ole yllättävää, että Namespaces-spesifikaation keskeisenä tavoitteena on, että käytettävien nimiavaruuksien nimet: 1) ovat ainutkertaisia ja pysyviä ja 2) ne omistaa "niitä vastaavia URIa hallinnoiva taho" Mikään virallinen taho ei tietenkään hallitse tätä sanktioiden avulla (vielä?), vaan kyse on käytännöllisestä sopimuksesta ja uskottavuudesta Huomaa, että attribuutin xmlns nimen suhteen ei tapahdu törmäyksiä, koska xml-alkuiset nimet on varattu W3C:n omaan käyttöön Namespacesin oma nimiavaruus on oletusarvoisesti http://www.w3.org/xml/1998/namespace. Tämä sitoo automaattisesti kaikki xml-alkuiset nimet. Nimiavaruuden prefiksi pitää siis antaa Namespacesnimiavaruusdeklaraatiossa kaikille muille prefikseille paitsi merkkijonoille "xml" ja "xmlns" 73275 RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 352
XML 1.0 -spesifikaatio ei "tunnista" nimiavaruuksien olemassaoloa, mikä käytännössä näkyy XML DTD-määrittelyjen kömpelyytenä (erityisesti prefiksien osalta). XML 1.0 -prosessori ei siis (välttämättä) tiedä nimiavaruuksista mitään, eikä siten myöskään löydä nimiavaruuksien käyttöön liittyviä virheitä Ikävien yllätysten välttämiseksi kannattaakin käyttää nimiavaruuksien prefikseinä aina spesifikaatioiden antamia esimerkkiprefiksejä, mikäli suinkin mahdollista (ts. jos tämä ei aiheuta törmäyksiä oman sanaston kanssa) Esimerkki: yksinkertainen XML-hypertekstilinkki määritellään tyypillisesti näin: <element xmlns:xlink="http://www.w3.org/1999/xlink"> <mylink xlink:type="simple" xlink:href="def.xml"> See the definition. </mylink> </element> määrittely olisi kuitenkin voitu antaa yhtä hyvin esim. (identtisessä) muodossa ("laiskasti" implementoitu selain ei kuitenkaan nyt välttämättä huomaa linkkiä) <element xmlns:z="http://www.w3.org/1999/xlink"> <mylink z:type="simple" z:href="def.xml"> See the definition. </mylink> </element> Esimerkin vaikutukset ovat selvät: linkit toteuttavan XML-prosessorin näkökulmasta on helpompaa "etsiä avainsanoja" xlink:type jne. kuin toteuttaa XML Namespaces -spesifikaatio (erityisesti kvalifioitujen nimien semantiikka) 73275 RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 353
Luennoitsija jorisee ("reflektoi"): mitäs seuraavaksi? Kun tarkoituksena on esitellä XML-standardiperhettä hypermedian näkökulmasta "loogisessa" järjestyksessä, olisi seuraavaksi toisen "ydinspesifikaation", XPathin pedanttisen läpikäymisen vuoro, jne. Kurssin aikataulu ei tähän mahdollisuuksia tarjoa, ikävä kyllä. Kurssin ideana on luoda tikapuut, kiivetä näillä tikapuilla talon katolle ja ihailla maisemaa. Jotta maisemasta ehdittäisiin kurssin puitteissa saada edes jonkinnäköinen aavistus, pitää tahtia jatkossa kiristää. Maiseman ihailuun nyt kannattaa tikapuiden jämäkkyyden kustannuksellakin ilmeisesti pyrkiä. Käytännössä tämä tarkoittaa sitä, että esityksen tarkkuudesta tingitään kurssin loppua kohden entistä enemmän. Suuren Mahtajan XML-standardiperheeseen liittyvän suunnitelman näkökulmasta Namespaces ja XPath ovat vain välietappeja matkalla kohti "korkeampia tavoitteita", kuten esim. XML-hypertekstiä (XLink) ja transformaatioita (XSLT). Tämä on suunta, johon "useimmat" XML-kehittäjät pyrkivät. Motivaationa on tyypillisesti hyvä "hinta/laatu"-suhde; käyttöön saadaan tätä kautta rikasta menetelmäkoneistoa suhteellisen vähäisellä tieto- ja työmäärällä. 73275 RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 354
"Paljaan" XML 1.0:n näkökulmasta toinen keskeinen looginen kehityksen suunta on kohti prosessoriohjelmointia. Tällöin ideana on kirjoittaa XML-dokumentteja käsittelevät (ja tulkitsevat) ohjelmat itse. Tähänkään työhön ei tarvitse ryhtyä puhtaalta pöydältä, sillä myös näitä menetelmiä on standardoitu ja parsereihin on tarjolla valmiita ohjelmointirajapintoja (vähentää uudelleenkeksimistä suuresti). Ao. kuva hahmottaa XML-soveltajan työn suunti OMA PROSESSOINTI- TOTEUTUS (ESIM. "SAX vs. DOM") "MUUT RÄÄTÄLÖIDYT SOVELLUKSET" VUOROVAIKUTUS XML LÄHDE- DOKU- MENTTI TRANSFOR- MOINTI (XSLT) RENDEROINTI (ESIM. CSS) XML KOHDE- DOKU- MENTTI RENDEROINTI (ESIM. XSLFO) "KATSELEMINEN & NAVIGOIMINEN" XML-STANDARDIEN MUKAISESTI OMAN RIIPPUMATTOMAN SOVELLUSKEHITYKSEN ALUE: SOVELLUKSET KIRJOITETAAN ITSE (JAVA, C++, VB, Perl, ). TYÖN TUKENA ESIMERKIT JA VALMIIT APIT XML-STANDARDIPERHEEN ALUE: KÄYTTÖSSÄ VALMIITA SOVELLUKSIA JA OHJELMISTOJA (ESIM. SELAIMET JA MUUT XML- JA XSLT-OHJELMISTOT) Visiot on taas visioitu. On aika jatkaa konkreettisempien asioiden käsittelyä 73275 RAKENTEISET DOKUMENTIT (kevät 2002) luentorunko ON 355