2 Rakenteisten dokumenttien perusteet Kuten todettua, rakenteinen dokumentaatio tähtää tiedon mallintamiseen käytössä olevien välineiden mahdollisuudet huomioiden (tietokoneet!). Tavoitteet ovat yleensä pitkäjänteisiä. Merkittävä osa rakenteisuudella tavoiteltavista hyödystä realisoituu esim. dokumenttien hallinnan sovelluksissa. Vrt. dokumentin kärjistetty elinkaari: Luonti Muokkaus Tarkastus Hyväksyntä Julkaisu Haku Katselu Arkistointi Kuva: Anttila, 2001 Poisto 20
2.1 Mikä on rakenteinen dokumentti? Rakenteinen dokumentti ~ rakenteellinen dokumentti ~ dokumentti, jossa erotetaan toisistaan dokumentin a) sisältö, b) rakenne ja c) ulkoasu (tai esitystapa) jotakin systemaattista ja yksikäsitteistä menetelmää käyttäen "Työvaiheet": 1) Tietorakenteen valinta (dokumentin tyyppi) Muistio (DTD)..kertoo kirjatuista tiedotteista yms. "Kerron pomolle, että uusi tietokantamme on susi" 0) Asiasisällön määrittäminen (sovellusalue) 3) Käsittely (esim. ulkoasun valinta ja julkaiseminen) 2) Asiasisällön koodaus (merkkaus) PENA OY MEMO 1.1.2000 To: Pentti Pomo Fr: Timo Työmies Uusi tietokantamme on susi! 4) Tulkinta 21
2.2 Huomautuksia Ilmeisestikin dokumenttien sisältö, rakenne ja ulkoasu voidaan eriyttää vain jos käytetyt välineet sen sallivat! (tietokoneet!) Oikeissa sovelluksissa työvaiheiden (0-)1-2-3 tunnistaminen, suunnittelu, toteuttaminen ja ohjeistaminen on joskus hyvin vaikeaa - tarvitaan tietoa sovellusalueesta, tiedon käsittelytekniikoista ja mallintamisesta (sekä työn reunaehdoista ja rajoitteista) Käytännössä tietoa yritetään yleensä esittää tunnettujen dokumenttityyppien avulla, ts. tulos on aina kompromissi olemassa olevien sovellusten ja välineiden sekä mallinnuksen tarkkuuden välillä Käytännössä "tiedon tilaaja" (esim. kustantaja, asiakas) yleensä määrittelee missä muodossa tieto pitää toimittaa (!) 22
2.3 Tyypillinen julkaisu-case: monikanavajulkaiseminen (Osa)tavoitteita: hallittavuus, siirrettävyys, yhteensopivuus, haettavuus, ohjelmistoriippumattomuus,... XHTML SMIL XML SVG PNG... XSL/FO PDF Sovellus #1 käsikirjoitus XSL CSS Sovellus #2 Mediaobjektit XLink XSL CSS Sovellus #3 23
2.4 Tieto: tahroja paperilla vai merkkejä rakenteessa? Rakenteisuuden perusidea: tekstinpätkän merkitys riippuu sen sijainnista dokumentissa (loogisen rakenteen suhteen) <a href="yhteystiedot/">yhteystiedot/</a> Erityyppisen tiedon erottaminen toisistaan perustuu sopimukseen merkkauksesta (merkkauskielioppi) - teksti = merkkaus + merkkidata - esim. HTML-dokumentti ja CSS-tiedosto; molemmat ovat tekstitiedostoja - esim. XHTML-dokumentti ja SVG-dokumentti; molemmat ovat tekstitiedostoja ja molempien merkkauskielioppi sama (XML), mutta tyyppimääritysten ansiosta elementtien nimet ja merkitys ovat erilaisia (ns. itse-kuvailevat dokumentit (self-describing)) Tietorakenne on "kaikki"; rakenteisella dokumentilla ei tarvitse olla sen kummempaa ulkoasua - vrt. RSS-tiedosto, lokitieto, viesti tietokoneohjelmien välillä (XML = Extensible Markup Language, SVG = Scalable Vector Graphics, CSS = Cascading Stylesheets) 24
2.5 Looginen ja fyysinen rakenne Dokumentin käsittelyn kannalta keskeistä on sen looginen rakenne Tuttu esimerkki: XHTML-dokumentti (ks. musiikki.html, musiikki.xml) Dokumentin looginen rakenne on dokumentin jäsennys tietyn kieliopin suhteen (esim. XML-pohjainen XHTML 1.0 Strict dokumenttityyppi) - juurielementti, elementit, attribuutit,..., tuloksena esim. tietyn XHTML-dokumentin looginen jäsennyspuu - (jäsennys)puu on rekursiivinen tietorakenne (puun alipuu on puu)...tästä on suurta hyötyä ohjelmoinnissa Dokumentin fyysinen rakenne on kokoelma (loogisen) dokumentin taustalla vallitsevia tiedostoja, tietorakenteita, yms. entiteettejä tietokoneen muistissa - esim. tiedosto(t) joihin HTML-dokumentti on talletettu 25
2.6 Dokumentin jäsennyspuu (XML) Esimerkki, listarakenne HTML-kielessä <ul lang="en"> <li>dire <br/> Straits</li> <li>pet Shop Boys</li> <li><img src="symbol.png" alt="prince"/></li> </ul> Iso ongelma: tyhjämerkit (!?) Peruskäsitteitä: ul li li li Dire br Straits Pet Shop Boys lang="en" img src="symbol.png" alt="prince" - solmu, juurielementti, elementti(solmu), attribuutti(solmu), tekstisolmu, tyhjäsolmu,..., juuri, lapsi, vanhempi, seuraaja, edeltäjä, sisar, edeltävä sisar, seuraava sisar, lehti(solmu) Huomaa: merkkaus tuottaa loogisia rakenteita - käytännössä jäsennyspuu "näkyy" aina vain ohjelmointirajapinnan läpi - jäsennyspuille on useita merkitsemistapoja (esim. attribuutit jätetään usein pois)...koska jäsennys suoritetaan aina jotakin tiettyä tehtävää silmälläpitäen (vrt. kommenttien näkyvyys jne.) 26
2.7 Dokumentin jäsennyspuu, huomioita Jäsennyspuun tulisi aina olla yksikäsitteinen ("XML:n pulma, ei meidän") -...muuten dokumentin käsittely ei onnistu - ikävä kyllä tietorakenteiden (tulkinnan) määrittelyistä löytyy toisinaan epätarkkuuksia tai suoranaisia virheitä Yksi ja sama jäsennyspuu voidaan tuottaa eri merkkausrakentein tai fyysisin rakentein -...tämä aiheuttaa toisinaan pulmia, koska ihmiselle merkityksellisiä merkkausrakenteita saattaa "unohtua" ohjelmallisessa prosessointiaskeleessa <b><div>ks. kuva A1: <img src="a1.png" alt="jalkapallo"/></div></b> jäsennys <!-- versio 2: --> <b> <div>ks. kuva A1: <img alt="jalkapallo" src="a1.png" /> </div> </b> jäsennys 27
2.8 Mikä sitten on dokumentti? Dokumentti on aistittavaksi ja ymmärrettäväksi tarkoitettu tietokokonaisuus, joka koostuu yhdestä tai useammista fyysisistä osista (esim. tiedostoista) ja voidaan sen loogisen rakenteen pohjalta jäsentää merkityksellisiksi osiksi Dokumenttien käsittelyssä (prosessoinnissa) erotetaan yleensä - lähdedokumentti (joskus käsikirjoitus) ja kohdedokumentti (tai tulosdokumentti) - asiayhteydestä riippuvia, suhteellisia käsitteitä d Sovellus / prosessointi d'..... Tietokoneiden myötä dokumentti voi olla paitsi staattinen (pysyvä) myös dynaaminen (esim. pyyntöhetkellä ohjeen mukaisesti kasattu) 28
2.9 Teksti, dokumentit, tulkinta ja käsittely Tarkoituksesta riippuen, (nyt lähinnä tekstimuotoinen) informaatio on mahdollista jäsentää tai tulkita dokumenteiksi usein eri tavoin, käsittelyn eri tasoilla <!ELEMENT <!ENTITY AB "Abe Lincoln"> Tulkinta (kenties koostaminen, ajonaikainen tuotanto) <?xml version="1.0"?> <!DOCTYPE poem [ <!ENTITY % names "http://1.2.3.4/names.ent"> %names; ]> <poem> There is no use of cursing darkness <author>&nn;</author> </poem> Prosessointi "There is no " Tekstidokumentteja (Unicode) XML-dokumentti Artikkeli, WWW-sivu, CD-rom, DVD, nauhoite,... Jokaiseen dokumenttiin liittyy aina jokin koodaus, sisältö, rakenne ja ulkoasu sekä ajatus sen käsittelystä (ns. oletus- tai luonnollinen tulkinta) 29
2.10 Dokumentin tyyppi ja dokumenttiluokka Tietojenkäsittelyn järkevöittämiseksi dokumentit ovat yleensä tietyn tyyppisiä - "HTML-sivua käsitellään eri tavalla kuin SVG-kuvaa" -...ohjelmoinnin tarpeet! Dokumentin tyyppi(määritys) on ohje joka kuvaa samantyyppisten dokumenttien dokumenttiluokan - yksittäisiä dokumentteja (tai näiden esiintymäosaa...) kutsutaan toisinaan (tietyn dokumenttiluokan) esiintymiksi (instance) tietyntyyppinen dokumentti (esim. "HTML-sivu") tietty dokumenttityyppi (esim. HTML, SVG, DocBook tai RDF/XML) tyyppimäärityskieli (esim. XML 1.0 tai XML Schema) merkkauskieli(oppi) (esim. XML 1.0) merkistö (esim. Unicode) Dokumenttiluokkien ja dokumenttien käsittely sisältää useita tekniikoita - esim. "saman" dokumenttiluokan voi periaatteessa määritellä useilla tyyppimäärityskielillä (DTD = Document Type Definition, dokumentin tyyppimääritys) 30
2.11 Esimerkki, XHTML Tuottajan näkökulma Tulkitsijan ja käsittelijän näkökulma Huomioita - rajapinta-ajattelu ("pienen yhteinen tekijä") - sovellus voi käytännössä [typedef] music.html [typedef] home.html DTD XHTML 1.0 Strict tuotanto käsittely (sovellus) [implements] toteuttaa dokumenttityypin käsittelyn usein eri tavoin Dokumentin tyyppi on vain (pieni) osa koko systeemiä - ohjeistus ja (ihmisille tarkoitettu) määrittely? - arkisissa sovelluksissa tarvitaan yleensä useita dokumenttiluokkia (joiden välillä on riippuvuuksia) 31
2.12 Dokumenttijärjestelmistä Huom. Rakenteisia dokumentteja käytetään toki muuhunkin kuin julkaisemiseen, mutta ideatasolla tästä on hyvä lähteä liikkeelle Pelkistetyn dokumenttijärjestelmän osat Dokumenttiprosessori(t) Dokumenttistandardi(t) Tuotantoprosessin suunnittelu- ja hallintavälineet Dokumenttitietokanta Dokumenttieditori Tyyppimääritystietokanta 10010100 10010010 01001011 01101010 10101000 10111111 Sovellukset (esim. mediakohtaiset ulkoasut) Objektitietokanta Objekti-editori Jäsennin ja validaattori Tyylitietokanta Käytännössä tarvitaan siis 1) standardeja, 2) ohjelmistoja, 3) teknisiä alustoja, 4) menetelmiä sekä 5) oikeita sovelluksia ja käyttötapoja 32
2.13 Dokumentti- vs. datalähtöinen mallintaminen Dokumenttilähtöinen mallintaminen jäsentää tiedon kokonaisuuksiksi jolla on tyypillisesti hierarkkinen rakenne - dokumentit muodostavat kokonaisuuksia ja käsitellään kokonaisuuksina - esim. Web-sivu, muistio, kirja, vektorikuva Datalähtöinen mallintaminen tarkastelee tietoa "pieninä dokumentteina" (tai tietueina) joiden tietosisältöä yhdistellään sovelluksessa melko vapaasti - esim. uutistieto, CD-levyn kappaletiedot, yhteystieto, metatieto, viesti Rajanveto on häilyvä; yleensä kyse on tavasta jolla tietoa tuotetaan - "käsin kirjoitettavaksi" tarkoitettu tieto on yleensä dokumenttilähtöistä ja sovellusalueeltaan melko rajattua - datalähtöistä tietoa käsitellään yleensä hakujen tai loogisesti kuvailtujen prosessien puitteissa (jolloin tietoa tarvitaan esim. tietyn säännön aktivoituessa) 33
2.14 Rakenteettomat dokumentit? Kommunikoinnin näkökulmasta rakenteettomia dokumentteja ei tietenkään ole olemassakaan (ja perinteisten tietokoneohjelmien tapauksessa rakenteiden on oltava ainakin luettavissa yksikäsitteisesti) Rakenteisuudessa on siis kyse lähinnä - kenen tai minkä tehtävän näkökulmasta rakenteita merkataan & kuka merkkauksen ymmärtää - miten yksityiskohtaisesti ja miten rakenne esitetään Tietokoneen näkökulmasta rakenteisuus tarkoittaa käytännössä sitä, että tietoa lukeva järjestelmä osaa sijoittaa luetun tietoalkion oikeaan paikkaan omassa tietorakenteessaan (tai osaa sivuuttaa sen tarpeettomana) Rakenteellisuus ei kuitenkaan ole vain staattisten dokumenttien ominaisuus; esimerkiksi yksinkertaiset sähköpostiviestit voidaan koodata tarkkaa SMTPetikettiä (protokollaa) noudattaen (Simple Mail Transfer Protocol) 34
2.15 Esimerkki: SMTP-keskustelusta S: MAIL FROM:<Smith@Alpha.ARPA> R: 250 OK S: RCPT TO:<Jones@Beta.ARPA> R: 250 OK S: RCPT TO:<Green@Beta.ARPA> R: 550 No such user here S: RCPT TO:<Brown@Beta.ARPA> R: 250 OK S: DATA R: 354 Start mail input; end with <CRLF>.<CRLF> S: Blah blah blah... S: <CRLF>.<CRLF> R: 250 OK Huomioita: - tarkkaan sovittu rakenne, erikoismerkkien pulma ja <CRLF>.<CRLF> - voitaisiin hoitaa (vieläpä paremmin?) myös lähettämällä rakenteisia dokumentteja osapuolten välillä (...Web Services) 35
2.16 "Muuntyyppisiä tietorakenteita kuin dokumentteja" Erotinmerkkeihin perustuvat tekstitiedostot (CSV jne.): # seuraavat ovat kappaleiden tietoja Sultans of swing 3:55 1996 Dire Straits Dire Straits Yesterday, When I Was Mad 3:55 1993 Very Pet Shop Boys Relaatiotietokannat (esim. taulu tai relaatio Tracks [tyyppitiedot!]): name len year album artist Sultans of swing 3:55 1996 Dire Straits Dire Straits Yesterday, When I Was Mad 3:55 1993 Very Pet Shop Boys Tavoite sama, keskeisiä eroja rakenteisiin dokumentteihin verrattuna - tietorakenteen monimutkaisuus - käsittelyn ja ohjelmoinnin monimutkaisuus - ohjelmallinen käsittely ja std-sovellukset - haut, tehokkuus, optimointi, tarvittavat ohjelmat - kysy käsitellä dataa vs. dokumentteja - pyörän uudelleen keksiminen (toistuvat pulmat: jäsennys, merkkikoodaus, kieli, metatiedot, ohjelmointi,...) 36