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ä RAKENTEISET DOKUMENTIT (kevät 2005) - ON 126

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 - 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 RAKENTEISET DOKUMENTIT (kevät 2005) - ON 127

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;] RAKENTEISET DOKUMENTIT (kevät 2005) - ON 128

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 todella hämärän näköisiä dokumentteja; käytännössä kannattaa tietenkin pyrkiä yksinkertaisuuteen RAKENTEISET DOKUMENTIT (kevät 2005) - ON 129

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> RAKENTEISET DOKUMENTIT (kevät 2005) - ON 130

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 RAKENTEISET DOKUMENTIT (kevät 2005) - ON 131

7 DTD ja entiteetit: dokumentin fyysinen rakenne 7.6 (Ulkoiset) dataentiteetit XML tarjoaa myös keinon assosioida dokumentin kanssa "dataa" (voi 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> Yleensä vähänlaisesti käyttöä (yleensä tietty sovellus) RAKENTEISET DOKUMENTIT (kevät 2005) - ON 132

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ö, 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;> RAKENTEISET DOKUMENTIT (kevät 2005) - ON 133

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)> ]]> RAKENTEISET DOKUMENTIT (kevät 2005) - ON 134

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 esim. nimiavaruuksien käytön yhteydessä - dokumentin paloittelu tuotantotyön helpottamiseksi Suunnittelussa kannattaa 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) XML Schema ei määrittele entiteettejä...toisaalta tekniikka kehittyy muilta osin RAKENTEISET DOKUMENTIT (kevät 2005) - ON 135

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: <?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> RAKENTEISET DOKUMENTIT (kevät 2005) - ON 136

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 määrittelyyn ja käyttöön. Perusidea on suunnitella nimet Internetin domainnimistä tutun hajautetun nimeämiskäytännön mukaisesti: "jos haluat keksiä uuden yleiskäyttöisen nimen, johda nimi kotisivusi URL-osoitteesta" RAKENTEISET DOKUMENTIT (kevät 2005) - ON 137

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 RAKENTEISET DOKUMENTIT (kevät 2005) - ON 138

14 8.2 Peruskäsitteistä ja määrittelystä Nimiavaruuden nimi on mielivaltainen IRI-merkkijono (kansainvälinen URI) Tiettyyn sovellukseen liittyy sovelluksen sanasto Nimiavaruus on tietyn IRI-nimen (usein URL) avulla nimetty sanasto (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) ja viittauksissa kaikki tarpeellinen tieto merkataan XML-dokumentteihin 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ä kerroksena RAKENTEISET DOKUMENTIT (kevät 2005) - ON 139

15 8.3 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, sisäkkäinen käyttö mahdollista (mutta tarvitaan harvoin) - ei ulotu attribuuteille (ts. eivät oletuksena kuulu mihinkään nimiavar.) - voidaan kytkeä pois päältä (arvo "" ~ ei nimiavaruutta) RAKENTEISET DOKUMENTIT (kevät 2005) - ON 140

16 8.4 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> RAKENTEISET DOKUMENTIT (kevät 2005) - ON 141

17 8.5 Kvalifioitu nimiavaruus (2/2) Kvalifioitu nimiavaruusmäärittely tarjoaa keinon erottaa toisistaan nimiavaruuden nimen esittelyn ja sen (toistuva) soveltamisen 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) RAKENTEISET DOKUMENTIT (kevät 2005) - ON 142

18 8.6 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> RAKENTEISET DOKUMENTIT (kevät 2005) - ON 143

19 8.7 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 sieltä 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 muuttuu ratkaisevasti Käytännössä nimiavaruus tuottaa uuden (implisiittisen) solmutyypin XMLdokumentin jäsennyspuuhun - nimiavaruus vs. nimen lokaaliosa RAKENTEISET DOKUMENTIT (kevät 2005) - ON 144

20 8.8 Huomautuksia (2/2) Nimiavaruuksien ja erityisesti kvalifioitujen nimien käyttö monimutkaistaa dokumenttien käsittelyä ja hankaloittaa esim. dokumenttien paloittelua (lue: älä tee ohjelmallisesti ilman oikean XML-prosessorin tukea)... <e x1:a="1" x2:a="2" /> 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. XPathlausekkeissa (vrt. XSL-esimerkki edellä) ja tietyissä Semanttisen Webin sovelluksissa (mikä on tietyssä mielessä varsin ikävää) -...tarkoittaa että tietyt prefiksinimet ovat merkittäviä käytännössä RAKENTEISET DOKUMENTIT (kevät 2005) - ON 145

21 8.9 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ä on niin kömpelöä että hommaan ei yleensä edes kannata ryhtyä - 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ä) RAKENTEISET DOKUMENTIT (kevät 2005) - ON 146

22 8.10 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) > RAKENTEISET DOKUMENTIT (kevät 2005) - ON 147

23 8.11 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> RAKENTEISET DOKUMENTIT (kevät 2005) - ON 148

24 8.12 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 RAKENTEISET DOKUMENTIT (kevät 2005) - ON 149