7 DTD ja entiteetit: dokumentin fyysinen rakenne

Transkriptio

1 è è è DTD ja entiteetit: dokumentin fyysinen rakenne 7 DTD ja entiteetit: dokumentin fyysinen rakenne Tietojenkäsittelyssä kaikki tieto talletetaan jonnekin. XML-dokumenttien fyysinen rakenne määräytyy ns. entiteettien avulla. Entiteetti muodostuu aina automaattisesti kun XML-dokumentti määritellään ja talletetaan muistiin (dokumenttientiteetti). Erikseen määriteltäviä entiteettejä voidaan käyttää esim. tiedon järkevään paloitteluun. Entiteettien määrittely on osa XML:n DTD-kieltä. Validi XML-dokumentti määrittelee kaikki entiteettinsä. 140

2 è è è DTD ja entiteetit: dokumentin fyysinen rakenne 7.1 Entiteetit tiedon fyysisinä lokeroina Aina kun tietoa käsitellään, se pitää tallettaa jonnekin käsittelyn ajaksi XML 1.0 määrittelee tiedon fyysisen rakenteen entiteetti-käsitteen avulla - entiteetti on nimetty tietosäiliö; tiedosto-käsitteen yleistys Entiteetteihin liittyviä ominaisuuksia - sisäinen vs. ulkoinen (missä sisältö?) - teksti vs. data (jäsennetäänkö?) - (yleinen) vs. parametri (käyttö DTD- vai esiintymäosassa?) Dokumenttientiteetti 141

3 è è è DTD ja entiteetit: dokumentin fyysinen rakenne 7.2 Elementtien määrittelyn perusteet ([Yleisen] sisäisen teksti)entiteetin määritys näyttää esim. seuraavalta <!ENTITY copyright "Oy Firma Ab"> 1 2 Taas tiedon lokeroinnin idea: nimi (1) vs. sisältö (tai arvo) (2) Tekstientiteetin sisältö voi sisältää myös merkkausta; se jäsennetään auki entiteetin lukemisen yhteydessä (literaaliarvo vs. korvausteksti) - merkkiviittaukset ja parametrientiteetit avataan, muu jää esiintymäosaan Esimerkki <!ENTITY bigboys "AT&T;">... <DOC>Esimerkki suuresta yrityksestä: &bigboys;</doc> [Esimerkki erittäin suuresta yrityksestä: AT&T;] 142

4 è è è DTD ja entiteetit: dokumentin fyysinen rakenne 7.3 Oletusentiteettien määrittely, merkkaus arvona DTD määrittelee kaikki entiteettinsä, myös ns. oletusentiteetit Huomaa tuplaviittaukset määrittelyssä: <!ENTITY lt "&#60;"> <!ENTITY amp "&#38;"> <!ENTITY gt "&#62;"> <!-- tai ">" --> <!ENTITY apos "&#39;"> <!-- tai "&#39;" --> <!ENTITY quot "&#34;"> <!-- tai """ --> Esim. seuraava määrittely on aina virhe (miksi?) <!ENTITY lt "<"> Tekstientiteetit tarjoavat teknisen keinon kirjoittaa varsin mutkikkaita viittausrakenteita; käytännössä kannattaa tietenkin pyrkiä yksinkertaisuuteen 143

5 è è è DTD ja entiteetit: dokumentin fyysinen rakenne 7.4 (Yleiset) ulkoiset tekstientiteetit Ulkoiset tekstientiteetit mahdollistavat XML-dokumenttien paloittelun useiksi tiedostoiksi - käyttö vain dokumentin esiintymäosassa - sisältönä hyvin muodostettu XML-dokumentti (tai sen WF osa), jonka saa lisätä entiteettiviittauksen kohtaan - ei-validoiva jäsentämisprosessi saattaa kuitenkin jättää ulkoisen tiedoston jäsentämättä ja olla lisäämättä entiteettiviittauksen kohtaan (!) Esimerkki (huomaa taas SYSTEM-avainsana ja URI-viittaus) <?xml version="1.0"?> <!DOCTYPE doc [ <!ELEMENT doc (#PCDATA)> <!ENTITY chap01 SYSTEM "Story_Chap01.xml"> ]> <doc> &chap01; </doc> 144

6 è è è DTD ja entiteetit: dokumentin fyysinen rakenne 7.5 Hyvin muodostettu tekstientiteetti Ulkoiset tekstientiteetit voivat käyttää eri merkkikoodauksia (ainakin UTF-8 ja UTF-16) Ulkoinen tekstientiteetti voi alkaa ulkoisen tekstitentiteetin XML-esittelyllä joka vastaa käytännössä XML-esittelyä ilman standalonepseudoattribuuttia, esim. Käytännössä ulkoinen tekstientiteetti vastaa XML-dokumentin hyvin muodostettua osaa (tasapainotettu merkkausrakenne mutta kenties ilman yksikäsitteistä juurielementtiä), esim. <?xml version="1.0" encoding="iso "?> Ks. <a href=" saadaksesi lisätietoja. 145

7 è è è DTD ja entiteetit: dokumentin fyysinen rakenne 7.6 (Ulkoiset) dataentiteetit XML tarjoaa myös keinon assosioida dokumentin kanssa "dataa" (voi toki olla myös tekstimuotoista, mutta sitä ei vain haluta nyt jäsennettävän) Viittaus notaation välittää XML-sovellukselle kuinka tiedostoa tulisi käsitellä (XML-prosessori itse ei toki viittauksen sisältöä ymmärrä) Dataentiteettejä käytetään attribuuttien välityksellä tyyliin: <?xml version="1.0"?> <!DOCTYPE DOC [ <!ELEMENT DOC (#PCDATA)> <!ATTLIST DOC LOGO ENTITY #REQUIRED> <!NOTATION JPG SYSTEM "jpgview.exe"> <!NOTATION GIF SYSTEM "gifview.exe"> <!ENTITY jpglogo SYSTEM "acme.jpg" NDATA JPG> <!ENTITY giflogo SYSTEM "acme.gif" NDATA GIF> ]> <DOC LOGO="giflogo"></DOC> Nykyisin vähänlaisesti käyttöä (ei juuri esim. XML-perheen standardeissa) 146

8 è è è DTD ja entiteetit: dokumentin fyysinen rakenne 7.7 Parametrientiteetit (ulkoinen DTD-osajoukko) Yleisiä entitteettejä käytetään dokumentin esiintymäosassa, parametrientiteetit tarjoavat nimensä mukaisesti keinon parametrisoida ja paloitella dokumentin tyyppimäärittelyä (Sisäisen) parametrientiteetin määritys näyttää esim. seuraavalta <!ENTITY % cmodel "em quote"> Tyypillinen käyttö on elementtien tietomallien ja attribuuttien määrittelyn sieventäminen, esim. (huomaa viittauksen merkkausrakenne; %-merkki) <!ENTITY % cmodel "em quote"> <!ENTITY % coreattrs "id ID #IMPLIED title CDATA #IMPLIED"> <!ELEMENT example (#PCDATA %cmodel;)*> <!ATTLIST example %coreattrs;> 147

9 è è è DTD ja entiteetit: dokumentin fyysinen rakenne 7.8 Parametrientiteetit: DTD:n paloittelu ja parametrisointi Parametrientiteetit mahdollistavat ulkoisen DTD-osajoukon paloittelun; tyypillinen käyttö on esim. entiteettimääritysten tai "ajureiden" kierrätys <!ENTITY % entdecl SYSTEM "namelist.ent"> %entdecl; Yhdessä ns. ehdollisten DTD-lohkojen kanssa parametrientiteetit mahdollistavat jossain määrin yleiskäyttöisten DTD-ajurien kirjoittamisen <!ENTITY % detailed "IGNORE"> <!ENTITY % sparse "INCLUDE"> <![%detailed;[ <!ELEMENT book (comments*, title, body, supplements)> ]]> <![%sparse;[ <!ELEMENT book (title, body)> ]]> 148

10 è è è DTD ja entiteetit: dokumentin fyysinen rakenne 7.9 Huomautuksia entiteettien käytöstä Hyviä (tai yleisiä) käyttökohteita - dokumentin tyyppimäärityksen parametrisointi (hallittavuuden parantamiseksi) - merkkauslyhenteet (merkkidatassa, käyttöä esim. nimiavaruuksien lyhenteiden yhteydessä) - dokumentin paloittelu tuotantotyön helpottamiseksi Suunnittelussa kannattaa kuitenkin pitää huoli, että lähdedokumenttiin kirjataan vain sinne kuuluvaa tietoa (!) - tiedon & työnjako käsikirjoituksen ja sitä kuorruttavan tyylin välillä (lue: älä käytä entiteettejä tuomaan esim. ulkoasuun liittyvää vakiotekstiä rakenteiseen lähdedokumenttiin) Esim. XML Schema ei määrittele entiteettejä...toisaalta tekniikka kehittyy muilta osin 149

11 è è è DTD ja entiteetit: dokumentin fyysinen rakenne 7.10 Entiteettien tulevaisuus? XML-perheen (uusi) suositus XML Inclusions (XInclude) Version 1.0 sisältää XML-dokumenttien lohkomisessa tyypillisesti liittyvän tekniikan...jos ja kun välineiden (rikkaampi! vrt. XPtr...) XInclude -tuki toteutuu, entiteettien käyttö paloittelutehtävissä todennäköisesti vähenee (aina vain) Esimerkki (huomaa myös nimiavaruuksien käyttö -- tähän palataan kohta): <?xml version='1.0'?> <document xmlns:xi=" <p>this document has been accessed <xi:include href="count.txt" parse="text"/> times.</p> </document> (count.txt = [324387]) <?xml version='1.0'?> <document xmlns:xi=" <p>this document has been accessed times.</p> </document> 150

12 8 Nimiavaruudet Yleiskäyttöisten XML-sovellusten lisääntyminen johtaa tilanteeseen jossa tietyt nimet halutaan varata tiettyyn käyttöön. Sovellusten yhdistelyssä vaarana kuitenkin on että nimet menevät sovelluksissa sekaisin. Tietojenkäsittelyn 1-käsitteisyyden hengessä koneiden kontekstin tajuun ei kuitenkaan voi luottaa. XML-nimiavaruudet on tekniikka dokumenteissa esiintyvien elementtien ja attribuuttien nimien yksikäsitteiseen (globaaliin) määrittelyyn ja käyttöön. Perusidea on suunnitella nimet Internetin domain-nimistä tutun hajautetun nimeämiskäytännön mukaisesti: "Jos haluat keksiä uuden yleiskäyttöisen nimen, johda se kotisivusi URL-osoitteesta" 151

13 8.1 Esimerkki: XInclude-sovellus Yritetään rakentaa XInclude-sovellus ilman nimiavaruuksien käyttö (ks. edellinen luku) ei onnistu!...ts. keksitään "yleiskäyttöinen komento" include jota käytetään seuraavasti: <?xml version='1.0'?> <document> <p>this document has been accessed <include href="count.txt" parse="text"/> times.</p> </document> Kysymys: mitä tapahtuu jos dokumentin sanastoon (= elementtien ja attribuuttien nimet) jo sisältyy nimi include (jossain toisessa merkityksessä)? Vastaus: tapahtuu törmäys jossa riskinä on se, että homonyymit (saman nimiset, eri asioita tarkoittavat sanat) sekoittuvat (josta seuraa pulmia) Ratkaisu: koodataan nimi include (ja muut yleiskäyttöiset nimet) riittävän pitkällä nimellä jonka rakenne sovitaan sellaiseksi että törmäykset voidaan välttää (sovitaan nyt konteksti 152

14 8.2 Peruskäsitteistä ja määrittelystä Nimiavaruuden nimi on mielivaltainen IRI-merkkijono (~kans.välinen URI) Tiettyyn sovellukseen liittyy sovelluksen sanasto Nimiavaruuden avulla sanasto voidaan globaalisti nimetä IRI-nimen (usein URL) avulla (yleensä sovellusspesifi, esim. xhtml-, xinclude-, yms. sanastot) Toisin sanoen, jos ja kun halutaan välttää törmäyksiä, sanastot suunnitellaan nimiavaruuksien avulla (=sanastot nimetään globaalisti) ja viittauksissa kaikki tarpeellinen tieto nimistä merkataan XML-dokumentteihin (xmlns jne.) XML-perheen suositus Namespaces in XML (1.1) määrittelee jälkimmäisen, so. miten nimiavaruuksia merkataan dokumentteihin Nimiavaruus määritellään teknisesti XML 1.0 (1.1) -suosituksen EBNFtuottosääntöjen päälle rakentuvana uutena semanttisena mutta merkkausteknisesti läpinäkyvänä rakennetason kerroksena 153

15 8.3 Kaksi tapaa merkata nimiavaruus Elementin nimiavaruuden voi (ilmoittaa eli) merkata dokumenttiin kahdella eri tavalla: Oletusnimiavaruuteen perustuva merkkaus on käyttökelpoista silloin kun suurin osa dokumentin elementeistä kuuluu samaan nimiavaruuteen Kvalifioitujen nimien avulla elementtien nimiavaruus on helppo merkata yksi kerrallaan, erityisesti silloin kun sisarukset kuuluvat eri nimiavaruuksiin Ellei elementin nimiavaruutta merkata (tai jos se ei peri nimiavaruutta edeltäjältään), se ei kuulu mihinkään nimiavaruuteen Jos on tarvis, attribuuttien nimiavaruus merkataan kvalifioitujen nimien avulla; usein attribuuteille ei osoiteta nimiavaruutta (koska attribuuttien ajatellaan olevan konkreettisia elementtejä luonnehtivia abstrakteja määreitä ja "joka tapauksessa kuuluvat elementtiensä yhteyteen") 154

16 8.4 Oletusnimiavaruus Oletusnimiavaruuden syntaksi on "tuttua" jo XHTML:n yhteydestä <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" " <html xmlns=" xml:lang="en" lang="en"> <head> <title>virtual Library</title> </head> <body> <p>check <a href=" </body> </html> Ominaisuuksia: - käytännössä "XML-perheen universaali attribuutti xmlns" (vrt. xml:lang ja xml:space) - periytyy; jälkeläiset voivat vaihtaa nimiavaruuden xmlns-attribuutillaan - ei ulotu attribuuteille (ts. eivät oletuksena kuulu mihinkään nimiavar.) - voidaan kytkeä pois päältä (arvo "" ~ ei nimiavaruutta) 155

17 8.5 Kvalifioitu nimiavaruus (1/2) Kvalifioidun nimiavaruuden ideana on vähentää kirjoitustyötä ja tarjota keino asettaa myös attribuuttien nimiavaruus. Vrt. esim. XSL-muunnos <?xml version="1.0" encoding="iso "?> <xsl:stylesheet xmlns:xsl=" version="1.0"> <xsl:output method="html" indent="yes" encoding="iso "/> <xsl:template match="/"> <html> <head> <title>esimerkki</title> </head> <body> <xsl:for-each select="//album"> <p><xsl:value-of </xsl:for-each> </body> </html> </xsl:template> </xsl:stylesheet> 156

18 8.6 Kvalifioitu nimiavaruus (2/2) Kvalifioitu nimiavaruusmäärittely tarjoaa keinon erottaa toisistaan nimiavaruuden nimen esittely ja sen (toistuva) soveltaminen ko. sanaston merkkauksessa, esim. <xsl:stylesheet xmlns:xsl=" xmlns:xhtml=" version="1.0"> Kvalifioitu nimi koostuu nimiavaruuden prefiksistä ja nimen lokaaliosasta:...<xsl:template match="//xhtml:body">...</xsl:template> Ominaisuuksia: - voidaan käyttää myös attribuuteille - prefiksi näkyy (periytyy) kaikille lapsille (mutta kvalifioitu nimi ei pakota lasten nimiavaruutta) - prefiksi voidaan version 1.1 myötä myös kytkeä pois päältä (xmlns:p="") (käytännössä prefiksinimien "tihkuminen" on joskus ongelma) 157

19 8.7 Takaisin XInclude-esimerkkiin... Ts. osaamme nyt tulkita mitä seuraava tarkoittaa <?xml version='1.0'?> <document xmlns:xi=" <p>this document has been accessed <xi:include href="count.txt" parse="text"/> times. </p> </document>...ja tiedämme miksi seuraava (ideatasolla sama) lähestymistapa olisi "yleisesti ottaen paljon huonompi" (mieti!): <?xml version='1.0'?> <document> <p>this document has been accessed <Ossi-Nykäsen-ikioma-include-MAT-TTY-Suomi href="count.txt" parse="text"/> times. </p> </document> 158

20 8.8 Huomautuksia (1/2) Nimiavaruuksia käytetään sovelluksissa runsaasti; erityisesti kaikki yleiskäyttöiset tai standardoidut XML-sovellukset esittelevät yleensä oman nimiavaruuden Nimiavaruuden nimen osoittamasta (URL-)osoitteesta ei Webistä tarvitse löytyä yhtään mitään eikä XML-sovellus ole velvoitettu käyttämään verkkoyhteyttä osoitteesta voi kuitenkin löytyä ko. nimiavaruuden kotisivu (ns. namespace document) Nimiavaruuksien semantiikka rakentuu XML-merkkauskieliopin päälle - uusia vaatimuksia XML-prosessoreille: tuki nimiavaruuksille -...käsittely kuitenkin periaatteessa onnistuu ilman semantiikan tulkintaa, mutta tällöin dokumentin tulkinta yleensä muuttuu ratkaisevasti Käytännössä nimiavaruus tuottaa uuden (implisiittisen) solmutyypin XMLdokumentin jäsennyspuuhun (vrt. nimi, nimiavaruus ja nimen lokaaliosa) 159

21 8.9 Huomautuksia (2/2) Nimiavaruuksien ja erityisesti kvalifioitujen nimien käyttö monimutkaistaa dokumenttien käsittelyä ja hankaloittaa esim. dokumenttien paloittelua (opetus: älä tee ohjelmallisesti ilman oikean XML-prosessorin tukea)... <count prefixa:len="1" prefixb:len="2" />... <xsl:template match="//xhtml:body">...</xsl:template> Huomaa että tarkkaan ottaen prefiksinimiin liittyvä merkkijonotieto kuuluisi loogisesti vain merkkauskielioppiin, eikä sen tulisi näkyä sovellukselle... mutta - Käytännössä prefiksinimiä käytetään kuitenkin esim. XPath-lausekkeissa (vrt. XSL-esimerkki yllä) ja tietyissä Semanttisen Webin sovelluksissa (mikä on tietyssä mielessä erittäin ikävää) - Tämä tarkoittaa sitä että merkkauksen nimiin viitataan merkkidatasta, vaikka kyse on tietynlaisesta suunnittelun "kategoriavirheestä" (opetus: käytä aina samoja, standardien esittelemiä prefiksinimiä) 160

22 8.10 DTD ei tue nimiavaruuksia XML-skeemat Nimiavaruudet tekevät ratkaisevan pesäeron SGML:ään Erityisesti XML 1.0 (1.1):een sisältyvä DTD-kieli ei tarjoa semanttista tukea nimiavaruuksille; käytännössä DTD-kielen käyttö nimiavaruuksien yhteydessä onkin niin kömpelöä että hommaan ei yleensä kannata ryhtyä (muista kuitenkin esim. XHTML, SVG yms.) - lokaalin sovelluksen kääriminen on kuitenkin mekaanisesti helppoa Suositus XML Schema (XML-skeemat) määrittelee DTD:tä yleisemmän dokumenttien tyyppimäärityskielen - XML-kielioppi, tuki nimiavaruuksille ja tietotyyppien yhdistelylle, johdetut tietotyypit, säännönmukaiset lausekkeet, datatyypit,... Ei syvennytä tällä kurssilla, aiheeseen palataan Rakenteisten dokumenttien jatkokurssilla (osana rakenteisen kuvailutiedon laajempaa viitekehystä) 161

23 8.11 XML-skeemat, esimerkki (1/2) Esimerkkidokumentti, muistio <?xml version="1.0" encoding="iso "?> <!DOCTYPE muistio SYSTEM "muistio.dtd" > <muistio pvm=" "> <otsikko>xml-koulutus</otsikko> <asia>muista ilmoittautua koulutukseen </asia> <huom>katso ennakkotehtävät.</huom> </muistio> Sopiva tyyppimäärittely (DTD) <!ELEMENT muistio (otsikko, asia?, huom+) > <!ATTLIST muistio pvm CDATA #REQUIRED > <!ATTLIST muistio henk (on jfk th) #IMPLIED > <!ELEMENT otsikko (#PCDATA) > <!ELEMENT asia (#PCDATA) > <!ELEMENT huom (#PCDATA) > 162

24 8.12 XML-skeemat, esimerkki (2/2) <xsd:schema xmlns:xsd=" <xsd:element name="muistio" type="muistiotype"/> <xsd:complextype name="muistiotype"> <xsd:sequence> <xsd:element name="otsikko" type="xsd:string"/> <xsd:element name="asia" type="xsd:string" minoccurs="0"/> <xsd:element name="huom" type="xsd:string" maxoccurs="unbounded"/> </xsd:sequence> <xsd:attribute name="pvm" type="xsd:date" use="required"/> <xsd:attribute name="henk" type="henkilottype" use="optional"/> </xsd:complextype> <xsd:simpletype name="henkilottype"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="on"/> <xsd:enumeration value="jfk"/> <xsd:enumeration value="th"/> </xsd:restriction> </xsd:simpletype> </xsd:schema> 163

25 8.13 Lopuksi Nimiavaruuksien merkkauskielioppi on melko ikävän näköistä; sovelluksissa asialla on kuitenkin vähänlaisesti merkitystä Nimiavaruuksien myötä puitteet XMLtietojenkäsittelyn abstrahoinnille ja rikkaalle sovellusperheelle ovat nyt olemassa Lue: tähän asti XML-perheen esittely on tavallaan ollut "itsestään selvien" perustietojen läpikäymistä tästä eteenpäin suunnistamisen vaihtoehdot kasvavat räjähdysmäisesti (potentiaalisesti hyödyllisiä sovelluksia löytyy miltei kaikista kuviteltavissa olevista sovellusalueista) Hypermedian kontekstissa ja maksimihyödyn hengessä, valitsemme rakenteisen tiedon julkaisupainotteisen tien