Rakenteiset dokumentit, kevät 2008

Rakenteiset dokumentit, kevät 2008 MATHM-47150 Rakenteiset dokumentit, 6 op, kevään 4-5 periodeilla Kotisivu: Ks. http://matriisi.ee.tut.fi/hypermedia/fi/opetus/ Suoritustapa: Luennot, harjoitukset ja tentti. Porkkanapisteitä jaossa. Opettaja: Ossi Nykänen, TD303, vastaanotto to 13-14 <ossi.nykanen@tut.fi> 1

1 Johdanto Rakenteinen dokumentaatio lähtee liikkeelle siitä kuningasajatuksesta että tietoa (dataa) mallintava tietorakenne ja sen esitystapa tulee teknisesti erottaa toisistaan sovelluksissa. Motivaatio on tietojenkäsittelyn tehostaminen, usein vaiheistaminen ja tehtävien automatisointi esim. putkilinjastojen muodossa. Työ nojautuu tietoteknisten välineiden käyttöön. Keskeistä on kyky mallintaa tehtäviä ja tietorakenteita "oikein" sopivalla tarkkuudella, sovelluksen tarpeet, reunaehdot, prosessit ja välineiden mahdollisuudet huomioiden. Dokumenttien sijaan tietoa voidaan mallintaa myös datalähtöisesti. Laajemmin tarkasteltuna idea on nostaa tietojenkäsittelyn abstraktiotasoa kohti merkityksen kuvailua; tämä mahdollistaa prosessien paremman ohjaamisen sekä esim. "semanttisen tietojenkäsittelyn". Huomattava osa rakenteisten dokumenttien sovelluksista perustuu nykyään erilaisiin XML-tekniikoihin (Extensible Markup Language). XML joka tarjoaa yhteensopivat puitteet lähes kaikentyyppisiin sovelluksiin. XML:n keskeinen rooli on määritellä täsmälliset rajapinnat sovellusten tietosisällön kuvaamiseen ja sovellusohjelmointiin. 2

1.1 Välisoitto ATK tähtää tehtävien automatisointiin Tämä onnistuu vain kuvaamalla tieto ja tehtävät siten että niiden mekanisointi on mahdollista Vaatimuksena on usein myös työtapojen muutos:...käsityön siirtäminen tietokoneisiin helpottaa esim. kopiointia muttei välttämättä paranna tiedon hallittavuutta Motto: on helppo kritisoida, hankalampaa on "tehdä oikein" 3

1.2 Opintojakson sisältö Tällä opintojaksolla "Rakenteiset dokumentit" puhutaan mm. seuraavista asioista: - RD-taustaa ja peruskäsitteitä, XHTML-aasinsilta - XML-kieliopin määrittely, dokumentin tyyppimääritys - Nimiavaruudet, XSL-muunnokset ja sovellusohjelmointi - RD-sovellusten suunnittelun perusteet - Matkan varrella on toki myös sovellusesimerkkejä Huom. Kyse ei ole "HTML-kurssista"; HTML-kieltä käytetään aasinsiltana koska se pääpiirteissään "oletetaan tunnetuksi", kielellä on selkeä rooli RD-historiassa ja se on tärkeä RD-sovellus 4

1.3 "Opintojakson sisältö yhdellä lauseella" Rakenteisten dokumenttien perusidea on tarkoituksenmukaisesti kuvata sovelluksen tietoa (järjestettynä) puurakenteena sekä asettaa täsmälliset rajapinnat ja tehtävät tiedon erityyppisten käsittelyaskelten välille. 5

1.4 Filosofinen huomautus termin "tieto" käytöstä Yleisesti voidaan määritellä esim. seuraava tiedon lajien erottelu: - kohina data ("rakenne") informaatio ("merkitys") tieto ("tulkitsija") tietämys ("tietotaito harkittuna osana tehtävää/tavoitteita"); Käytämme (suomen kielen) yläkäsitettä tieto tällä opintojaksolla kuitenkin varsin vapaasti - Idea: Ihmisillä on tehtäviin liittyvää tietämystä jossa tarvittavaa tietoa he kuvaavat datana, vaikkapa dokumenttien muodossa (tietorakenteet!). Dokumentit taasen välittävät informaatiota, joka edelleen tulkittuna voi taas "jalostua" tiedoksi ja tietämykseksi. - Koska ihmisten motiivi on aina "käsitellä tietoa", ei kielenkäytössä oikominen tässä liene suuri synti "Ja se siitä" Platon (427 347 eaa.) 6

1.5 Johdattelevia esimerkkejä rakenteisista dokumenteista (maalaus, eväsretki) kauppalappu "rakenteisuus" luentomuistiinpano näytelmäkäsikirjoitus artikkeli kirja tekninen piirustus tekstinkäsittelyohjelman tuottama dokumentti tietokoneohjelman talletustiedosto viesti tietokoneohjelmien välillä Hyviä huomioita "digitalisoinnista" - tarpeet? tuotannon tehokkuus? käsittelyn tehokkuus? toimijat? paloittelu? automatisointi? ohjelmointirajapinnat? käytössä olevat välineet? - standardit ja siirrettävyys? tiedon uudelleenkäyttö? versiointi ja virkistäminen? lisensointi? sitoutuminen yhteen toimittajaan? osaaminen?... 7

1.6 Dokumenttituotannon roolijaosta ( prosessi) Wanhaan hyvään aikaan tekstin prosessointi sujui kutakuinkin seuraavasti: - kirjoittaja kirjoitti käsikirjoituksen (kirjoituskoneella) ja lähetti sen kustantajalle - käsikirjoituksen hyväksymisen, oikolukemisen, editoimisen, yms. jälkeen kustantajan taittaja suunnitteli tuotettavan teoksen ulkoasun (sommittelu, taitto (layout)) kirjoittamalla käsin (merkkaamalla) ulkoasun ohjeet käsikirjoituksen marginaaliin (palstat, kirjasimet, fonttikoot, tekstin välistys, ) - seuraavaksi latoja latoi käsikirjoituksen annettujen ohjeiden perusteella, tuloksena konkreettinen ohje esim. kirjan painamiseksi (+kannet) - lopuksi tuotos julkaistiin käyttäen erilaisia markkinointi- ja jakelukanavia Erityyppisillä töillä siis eri vaiheet ja eri tekijät - tosin ammattikirjoittajat siirtyivät hiljalleen käyttämään suoraan myös erilaisia formatointikieliä 8

1.7 What You See Is What Yout Get (-live with it!) Nykyiset tekstinkäsittely- ja julkaisuohjelmat (ns. desktop publishing) tarjoavat näennäisen helpon tavan tehdä kaiken itse yhdeltä istumalta 80-luvulta alkanut WYSIWYG-buumi, hyvää: - kehittyneet ohjelmat helppokäyttöisiä ja intuitiivisia (työpöytämetaforat) - lopputuloksen nähtävissä jo kirjoitusvaiheessa - monipuolisia formatointi ja taitto-ominaisuuksia, Internetin myötä myös jakelu Ongelma: työstä tulee helposti käsityötä - dokumenttien suunnittelu jää helposti puolitiehen - suurten dokumenttien ylläpito hankalaa - tuloksena rakenteen rämettyminen ja kirjoittajan epäselvä rooli Ratkaisuja: hyvä suunnittelu ja ohjeistus (!), tyylit, etsi/korvaa-toiminnot, 9

1.8 Dinosaurus, joka elää & voi hyvin: LaTeX Kaikki eivät kuitenkaan kirjoita tuotoksiaan XX Wordillä - erityisesti korkeakoulumaailmassa huomattava osa akateemisista kirjoittajista vannoo LaTeXin nimeen TeX on (alunperin) tekstin ja matemaattisten kaavojen ladontaan tarkoitettu pitkän linjan tietokoneohjelma, jonka ensimmäinen versio julkaistiin 1982 (D. Knuth). Nykyään useille eri käyttöjärjestelmille LaTeX on TeXin varaan rakentuva makropakkaus avulla kirjoittajat voivat latoa ja tulostaa dokumentteja ammattimaisen taittomallin mukaisesti Työskentely LaTeXilla tapahtuu periaatteessa ohjelmankehitystyöstä tuttujen pelisääntöjen mukaisesti - kirjoittaja kirjoittaa lähdekoodit tekstimuodossa (ns. käsikirjoitustiedostot) tekstinkäsittelyohjelmalla.tex-tiedostoiksi - lähdekoodi käännetään (tyypillisesti komentorivipohjaisella) latexohjelmalla graafiseen muotoon.dvi-tiedostoiksi, joka voidaan edelleen muuntaa tulostettavaan muotoon (tai lähdekoodia voi korjata) 10

1.9 LaTeX-esimerkki Tyypillinen TeX-tiedosto näyttää seuraavalta: \documentclass[a4paper]{article} \begin{document} \title{latex-example} \author{ossi Nyk\"{a}nen} \maketitle \abstract{this article demonstrates LaTeX basics. Read some introductionary book for details.} \tableofcontents \section{introduction} \LaTeX{} really is something, especially if you want to input equations in your text\footnote{assuming you know \LaTeX codes, that is.}. Here's an example: \begin{equation}\label{pred} \forall x \in X: P(x). \end{equation} 11

If you wan't to know what \ref{pred} means, please consult your elementary logic book. \section{functional Descriptions} Function is a map $t:x \to Y$. The family of XML specifications defines many languages that allow defining functions, e.g., the Extensible Stylesheet Transformation Language \cite{xslt}. \begin{thebibliography}{longtitle} \bibitem{xslt} "XSL Transformations (XSLT) Version 1.0", J. Clark, editor, 16 November 1999. Available at http://www.w3.org/tr/xslt \end{thebibliography} \end{document} 12

1.10 Huomioita Erikoismerkit, käskyt, kommentit sekä tiedoston rakenne Jos kaikki tarvittava on työkoneella valmiiksi asennettuna, kääntäminen Unixissa tai Linuxissa sujuu helposti komennolla latex koe.tex Dokumentin katselu ja ps-tiedoston tuottaminen tulostamista varten on yhtä helppoa: xdvi koe.dvi & dvips -o koe.ps koe.dvi Tuloksena on ammattimaisen ulkoasun omaava sivupahanen, jossa ilmaiseksi saatiin varsin paljon dokumentin rakenne LaTeX-komennoilla merkkaamalla: - palstoitus ja marginaalit (alaviittaus) - eri tyylit tekstin eri osille (otsikko, tiivistelmä, vakiokentät, ) - otsikoiden numerointi, kaavan numerointi & viittaukset, jne. 13

1.11 Olennaista: keskittyminen sisältöön! Juuri tämä on LaTeXin idea: systeemi tarjoaa ammattimaisen rakenteen ja ulkoasun, kirjoittajan keskittyessä olennaiseen, eli sisällön tuottamiseen LaTeX-systeemissä "LaTeX taittaa" ja "TeX toimii latojana" Kirjoittaja muotoilee tekstinsä ja sen rakenteen LaTeXin käskyjen avulla halutuksi, josta esitysversio sitten "käännetään" LaTeX pyrkii tekemään teksteistä paitsi hyvän näköisiä, ennen kaikkea luettavia (sisäänrakennettu typografinen malli & johdonmukainen rakenne) LaTeXista on eri versioita (mutta yleensä kyse on "painetuksi tarkoitettavien julkaisujen" tekemisestä...joskaan ei aina) WYSIWYG-käyttäjille LaTeX on aluksi "oma maailmansa" -- ideaan joko mieltyy (jälki on kaunista/ammattimaista) tai sitten ei (jos kirjoittaa vähän eikä tarvitse esim. kaavoja, Latex saattaa tuntua aluksi turhan työläältä). 14

1.12 World Wide Web & HTML Internetin suosion myötä tietoverkkojen arvo kaikenlaisen informaation levittelyssä huomattiin. Kirjoittaminen ei vain saisi olla kohtuuttoman vaikeaa WWW:n lanseeraama HTML esitteli 90-luvun alussa suurelle yleisölle yksinkertaisen mutta rakenteellisen merkintäkielen Tim Berners- Lee - idea: teksti + yksinkertainen merkkaus - nopea oppia perusideat leviävät ja HTML otetaan todella nopeasti laajamittaiseen käyttöön Ongelmia: - helppous johtaa löysyyteen, merkkaus sekaisin rakenne- ja ulkoasumäärityksiä ja selaimet kuittaavat merkkausvirheitä arvailemalla - ulkoasullisesta rajoittuneisuudesta johtuen kuvaileva merkkaus ei saa suosiota, vaan koodeja aletaan käyttää myös formatointiin Tulos: HTML lipsuu kohti formatointikieltä: WWW-WYSIWYG. Ei hyvä Oppiminen tapahtuu kantapään kautta: takaisin sorvin ääreen...(x)html 15

1.13 (X)HTML-esimerkki Tyypillinen (X)HTML-tiedosto näyttää seuraavalta: <?xml version="1.0" encoding="iso-8859-1"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/tr/xhtml11/dtd/xhtml11.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head><title>html-esimerkki</title></head> <body><!-- Tästä se alkaa... --> <h1>johdanto</h1> <p>valitse HTML kun haluat liittää kuvia ja linkkejä <em>websivulle</em> (ja tunnet HTML-merkkauksen perusteet). Esimerkki:</p> <p><img src="kuva.gif" alt="kuva"/> <a href="http://matriisi.ee.tut.fi/hmopetus/">hm ammattiaineen kotisivut</a></p> <p>jos et ymmärrä tämän dokumentin merkitystä, käy läpi HTMLkielen perusteet.</p> </body> </html> Huomaa: elementit, erikoismerkit, kommentit sekä dokumentin tyyppi 16

1.14 Mekaanisesti käsiteltävän tiedon kolme tasoa Aivan kuten esim. tietokantojen tapauksessa, myös rakenteisten dokumenttien yhteydessä voidaan tunnistaa kolme tiedon tasoa: - käsitetaso (kohdetaso) ~ " ihminen " - rakennetaso (looginen taso) ~ " sovellusohjelma " - talletustaso (fyysinen taso) ~ " massamuisti " Rakenteen valinta kiinnittää sen, mistä dokumentissa voidaan suoraan viestiä, esim. HTML-sovelluksen tapauksessa rakennetaso on dokumenttityypin valinnalla kiinnitetty pitkälti HTML-sanastoon - rakenne ei välitä epäsuoraa viestiä, joskin tulkitsija saattaa sen ymmärtää (ja esim. mikroformaattien yms. käyttö kuitenkin tarjoaa hallitun "porsaanreiän" ulkoisten sanastojen käyttöön ja suoraan viestintään) Ideaalitapauksessa rakennetaso vaihdetaan käsitetason ehdoilla, käytännössä, esim. legacy-syistä johtuen, näin ei voida aina tehdä 17

1.15 Mikä (X)HTML:ssä sitten on vikana? Ei niin paljoa kuin kuulee toisinaan väitettävän -- pulmat syntyvät vääristä olettamuksista Esimerkki: Halutaan julkaista laaja ohjekirja verkossa - HTML määrittelee vain rajapinnan joka mahdollistaa Websivujen kuvailun niin, että selaimet osaavat esittää niitä käyttäjille (usein käyttöliittymäkomponentteihin sulautuneena; esim. sisällysluettelo, murupolku, jne.) - käsikirjoitusta ei ole järkevä tuottaa/ylläpitää HTML-muodossa -...vaan sellaisessa muodossa... - jossa tekstin jäsentäminen, ylläpito ja tulostaminen on helppoa - johon voidaan esim. merkitä tieto asiasanoista ja lähdeviittauksista järkevästi, erottaa esipuhe yhteenvedosta jne. Ratkaisuja: DocBook? Oma dokumenttityyppi? Tietokantaesitys?... 18

1.16 Mikä WYSIWYG:issä sitten on vikana? Ei niin myöskään paljoa kuin kuulee toisinaan väitettävän -- pulmat syntyvät vääristä olettamuksista Esimerkki: Halutaan kirjoittaa laaja ohjekirja - WYSIWYG-kirjoittaminen tarjoaa helpon ja intuitiivisen tavan editoida yksittäisiä dokumentteja -...mutta on riski piilee siinä, että esim. julkaisussa tarvittavat rakennetiedot (kappaleet, asiasanat, viittaukset) merkitään epämääräisesti tai teknisesti heikosti saatavissa olevassa muodossa -...tai ei ymmärretä koko asiaa - jos tavoitteena on käsikirjoituksen julkaiseminen eri formaateissa, ei myöskään pelkkään printtijulkaisuun tarkoitettu WYSIWYG riitä (!) Ratkaisuja: suunnittelu ja ohjeistus, tehtävään soveltuvan WYSIWYGeditorin valinta, turhien kirjoittamisen vapauksien rajoittaminen (!) ja testaus 19

1.17 Paluu juurille? Rakenteisten dokumenttien perusajatuksena on kohdistaa dokumenttien suunnittelun huomio oikeisiin kohtiin: - dokumenttien rakenteen suunnittelu asiasisällön (lue: käsittelyn) näkökulmasta, ei ulkoasun - tiedon ja sen käsittelyn paloittelu, komponenttiajattelu (dokumenttien peruspalasia ovat elementit, käsittely koostuu vaiheista) - looginen rakenne eriytetään esitystavasta: ulkoasun ei ole pakko vastata sisällöllistä rakennetta ja päinvastoin Kyseessä ei ole uusi asia! - rakenteisten dokumenttien moderni esiinmarssi alkoi käytännössä SGML-standardin (ISO 8879:1986) valmistuttua 1986 - SGML:n kehitys alkoi 1980, pohjana IBM:n GML (Generalized Markup Language) vuodelta 1969! (Goldfarb, Mosher, Lorris) Charles F. SGML osoittautui "liian" raskaaksi standardiksi (esimerkiksi Goldfarb IBM, USA:n Puolustusministeriö) - suppea käyttö ei suosittua 20

1.18 Kerran vielä (pojat tytöt)! SGML:n idea on hyvä, mutta iso spesifikaatio (~500 sivua) W3C:n SGML wg: XML 1.0 vuonna 1998 (~30 sivua) - XML on SGML:n sovellusprofiili - sovelluksissa tarvitaan paljon muitakin standardeja, sekä välineitä ja sovellusosaamista Yleisöystävälliset tavoitteet - yhteensopivuus SGML:n kanssa ja sen hyvät puolet, dokumenttien sekä niitä prosessoivien ohjelmien suunnittelun ja lukemisen "helppous" - spesifikaatiossa vähän valinnaisia piirteitä ja soveltaminen täsmällistä - XML-dokumenttien käyttö (Internetissä) "yksinkertaista" (...ohjelmointi) Pulmia - luvassa suunnittelua, opiskelua, kirjoittajan roolin muutos, "byrokraattisuus/ teknisyys", editorit, tekstiformaatin huonot puolet,... XML-standardiperheen ydin tällä hetkellä stabiili ja XML:ää tukevien sovellusten kriittinen massa selvästi ylitetty (soveltajia, työkaluja, dataa) 21

1.19 Standardiesimerkki rakenteisesta dokumentista looginen rakenne fyysinen rakenne <doc><title> XML 10 vuotta </title> <body> Paljon onnea XML! </body></doc> 10011000 Sovellus / prosessointi www w3c tut XML 10 Paljon onnea XML! www.w3c.tut.f esitys / näkymä (joskus (kohde/tulosdokumentti") 10011000 <?xml version= 1.0?> <xsl:stylesheet rakenteinen (lähde-) dokumentti (käsikirjoitus) tyyli (esim. formatointi) kuva (mediaobjekti) 22

1.20 Käytännöllisiä haasteita Rakenteisen dokumentaation menetelmien ideat ja hyödyt ovat "tekniikan ammattilaisille" kohtuullisen opiskelun jälkeen melko selviä, esim. dokumentaation, tiedonhallinnan ja ohjelmistojenvälisen kommunikoinnin sovelluksissa Laajamittaisten ja avointen sovellusten toteuttaminen sen sijaan on suuri haaste koska "nopsaan koodaavat loppukäyttäjät" eivät aina ymmärrä tekniikoita - vrt. HTML-syntaksin ja wiki-syntaksin historiallinen kehitys ja "vanhojen virheiden toistuminen" Suuntaa-antavia lukuja (vuonna 2007): - legacy: 95% Web-sisällöstä on yhä toteutettu HTML 3/4 -tekniikoin - markkinat: esim. selainvalmistajat eivät ole toistaiseksi kovin aktiivisesti osallistuneet esim. XHTML-kielen kehitykseen/käyttöönottoon - trendi: jokaista mikrotietokonetta kohti on kymmenen mobiilipäätettä, HTML 5 tulossa (rajapinnat) 23

1.21 Huomioita RD-opiskelusta Vaikka aluksi tekniikka vie päähuomion, pitkällä juoksulla kyse on "taas kerran" tietoa tuottavien ja hallitsevien prosessien suunnittelusta ja ohjaamisesta Vaikka tekniikka X(ML) ei tarjoa viisastenkiveä, löytyy sen kautta sisältöä, välineitä, esimerkkejä ja "samaa kieltä puhuvia" osaajia WYSIWYG ei ole pahasta kyse on tehtävän suunnittelusta (myös esim. MS Wordille on saatavilla hyviä artikkelipohjia yms.); teknisen kirjoittajan on myös usein helpointa työskennellä WYSIWYG-kuorrutetun editorin varassa Asiat voi usein tehdä järkevästi useilla eri tavoilla, eri tekniikoita käyttäen Erityisesti, RD-ajattelua tai XML:ää ei kannata väkisin tunkea joka paikkaan, vaan pohtia menetelmien lisäarvoa suhteessa muihin ratkaisuihin turha dogmaattisuus on yleensä pahasta 24

è è è Rakenteisten dokumenttien perusteet 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 vasta "pitkällä aikavälillä". Vrt. dokumentin kärjistetty elinkaari: Luonti Muokkaus Tarkastus Hyväksyntä Julkaisu Haku Katselu Arkistointi Poisto Kuva: Anttila, 2001 25

è è è Rakenteisten dokumenttien perusteet 2.1 Välisoitto Ensimmäinen askel työn automatisoinnissa on prosessin haltuunotto Tämä tarkoittaa vähintäänkin eri työvaiheiden ja tekijöiden tunnistamista ja tietoa välittävien rajapintojen kuvaamista Mekaaniset tehtävät kannattaa yleensä jättää tietokoneiden tehtäväksi 26

è è è Rakenteisten dokumenttien perusteet 2.2 Dokumentti säiliöi ja välittää tiedon kirjoittajalta lukijalle 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) - nämäkin ovat asiayhteydestä riippuvia, suhteellisia käsitteitä d Sovellus / prosessointi d'..... Dokumentti voi olla paitsi staattinen (pysyvä) myös dynaaminen tai virtuaalinen (esim. koottu vasta pyyntöhetkellä jonkin ohjeen mukaisesti) 27

è è è Rakenteisten dokumenttien perusteet 2.3 Mikä sitten on "rakenteinen dokumentti"? Rakenteinen dokumentti ~ rakenteellinen dokumentti ~ dokumentti, jossa erotetaan toisistaan dokumentin a) sisältö, b) yleiskäyttöinen rakenne ja c) esitystapa (tai ulkoasu) jotakin systemaattista ja yksikäsitteistä menetelmää käyttäen. "Työvaiheet": Huomaa että dokumenttikäsite on suhteellinen: se esiintyy suhteessa työkaluihin ja käyttötapaukseen 2) Tietorakenteen valinta (dokumentin tyyppi) Muistio (DTD)..kertoo kirjatuista tiedotteista yms. "Kerron pomolle, että uusi tietokantamme on susi." 1) Asiasisällön määrittäminen (sovellusalue) 4) Käsittely (esim. ulkoasun valinta ja julkaiseminen) 3) Asiasisällön koodaus ("merkkaus") ACME OY Muistio 1.1.2000 To: Pentti Pomo Fr: Timo Työmies Uusi tietokantamme on susi! 5) Tulkinta / Käyttö sovelluksessa 28

è è è Rakenteisten dokumenttien perusteet 2.4 Huomautuksia Ilmeisestikin dokumenttien sisältö, rakenne ja ulkoasu voidaan eriyttää vain jos käytetyt välineet sen sallivat (onko esim. tietoa ilman tietorakennetta tai ulkoasua ilman fyysistä esitystä?) Tietokoneissa asiasisältö esitetään tietenkin aina suhteessa johonkin tietorakenteeseen Oikeissa sovelluksissa työvaiheiden 1-5 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 esim. dokumenttityyppien avulla, ts. tulos on aina kompromissi olemassa olevien sovellusten, välineiden, mallinnuksen tarkkuuden ja resurssien välillä Käytännössä "tiedon tilaaja" (esim. kustantaja, asiakas, jatkokehittäjä) yleensä määrittelee missä muodossa tieto pitää toimittaa 29

è è è Rakenteisten dokumenttien perusteet 2.5 Tyypillinen käyttötapaus: monikanavajulkaiseminen (Osa)tavoitteita: hallittavuus, siirrettävyys, yhteensopivuus, haettavuus, ohjelmistoriippumattomuus,... XML XHTML SVG SMIL PNG... XSL/FO PDF Sovellus #1 käsikirjoitus XSL CSS Sovellus #2 Mediaobjektit XLink XSL CSS Sovellus #3 30

è è è Rakenteisten dokumenttien perusteet 2.6 Rakenteinen teksti = merkkaus + merkkidata Rakenteisuuden perusidea: tekstinpätkän merkitys riippuu sen sijainnista dokumentissa (loogisen rakenteen suhteen) <a id="osoite" href="osoite/">osoite</a> Erityyppisen tiedon erottaminen toisistaan perustuu sopimukseen merkkauksesta (merkkauskielioppi) - rakenteinen teksti = merkkaus + merkkidata - esim. HTML-dokumentti ja CSS-tiedosto ovat molemmat tekstitiedostoja - esim. XHTML-dokumentti ja SVG-dokumentti ovat molemmat tekstitiedostoja ja molempien merkkauskielioppi sama (XML), niinpä looginen käsittely onnistuu yhden ja saman abstraktin XML-rajapinnan läpi - ns. itsensä kuvailevan dokumentin (self-describing) käsittely onnistuu " vain ko. dokumentti lukemalla" (rakenne? tyyppitieto? merkitys?) Tietorakenne on "kaikki" rakenteisella dokumentilla ei tarvitse olla sen kummempaa ulkoasua - talletustiedosto, asetukset, lokitieto, viesti tietokoneohjelmien välillä, (XML = Extensible Markup Language, SVG = Scalable Vector Graphics, CSS = Cascading Stylesheets) 31

è è è Rakenteisten dokumenttien perusteet 2.7 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 hyötyä ohjelmoinnissa; jokaisella solmulla implisiittinen nimi Dokumentin fyysinen rakenne on kokoelma (loogisen) dokumentin taustalla vallitsevia tiedostoja, tietorakenteita, yms. entiteettejä tietokoneen muistissa - esim. tiedosto(t) joihin HTML-dokumentti on talletettu 32

è è è Rakenteisten dokumenttien perusteet 2.8 Pelkistetty esitys XML-dokumentin osista Schema Entity 0..* 1 Stylesheet Entity Document Entity 0..* 1 1 0..* - DTD - Element content Data Entity 1 0..* Text Entity 33

è è è Rakenteisten dokumenttien perusteet 2.9 Looginen rakenne ja 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> Tyhjämerkkien tulkinta 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" ohjelmointirajapinnan (tms.) läpi - jäsennyspuille on useita merkitsemistapoja (esim. attribuutit ja tyhjäsolmut jätetään usein pois)...koska jäsennys suoritetaan aina jotakin tiettyä tehtävää silmälläpitäen (vrt. kommenttien näkyvyys jne.) 34

è è è Rakenteisten dokumenttien perusteet 2.10 Dokumentin jäsennyspuu, huomioita Yksi ja sama looginen jäsennyspuu voidaan usein 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 35

è è è Rakenteisten dokumenttien perusteet 2.11 Teksti, dokumentit, luonnollinen tulkinta Tarkoituksesta riippuen, (erit. tekstimuotoinen) informaatio on mahdollista jäsentää tai tulkita dokumenteiksi usein eri tavoin, käsittelyn eri tasoilla Jokaiseen dokumenttiin liittyy aina jokin koodaus, sisältö, rakenne ja ulkoasu <!ELEMENT <!ENTITY AB "Abe Lincoln"> Tekstidokumentteja (Unicode) 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> XML-dokumentti Prosessointi "There is no " Dokumentteja sovelluksen tasolla, esim. asiakirja, nettisivu, kuva... sekä ajatus sen käsittelystä (ns. oletus- tai luonnollinen tulkinta) Dokumenttilähtöisessä tiedon mallinnuksessa luonnollinen tulkinta on esim. eheä lokaali sovellus (esim. tuotteen käyttöohje), datalähtöisessä tiedon mallinnuksessa esim. yksittäisistä kontribuutioista rakentuva globaali sovellus (esim. itämeriportaali) 36

è è è Rakenteisten dokumenttien perusteet 2.12 Dokumentin tyyppi ja dokumenttiluokka (vrt. hei.txt, ) Tietojenkäsittelyn järkevöittämiseksi dokumentit ovat yleensä tietyn tyyppisiä - "HTML-sivua käsitellään/sovelletaan eri tavalla kuin SVG-kuvaa" -...tuotannon ja ohjelmoinnin tarpeet! tietyntyyppinen dokumentti, "esiintymä" (esim. "HTML-sivu") tyyppimäärityskieli (esim. XML DTD tai XML Schema) merkkauskielioppi (esim. XML) merkistö (esim. Unicode) tietty dokumenttityyppi (esim. HTML, SVG, DocBook tai RDF/XML) Dokumentin tyyppi(määritys) on ohje joka kuvaa samantyyppisten dokumenttien dokumenttiluokan (document class) - yksittäisiä dokumentteja (tai näiden esiintymäosaa...) kutsutaan toisinaan (tietyn dokumenttiluokan) esiintymiksi (instance) Dokumenttiluokkien ja dokumenttien käsittely sisältää useita tekniikoita - esim. "saman" dokumenttiluokan voi periaatteessa määritellä useilla tyyppimäärityskielillä (Esim. XML DTD, XML Schema ja Schematron) (DTD = Document Type Definition, dokumentin tyyppimääritys) 37

è è è Rakenteisten dokumenttien perusteet 2.13 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 luku/muokkaus selaimessa DOM-rajapinnan varassa, jne. Dokumentin tyyppi on vain (pieni) osa koko systeemiä - ohjeistus ja (ihmisille tarkoitettu) määrittely - arkisissa sovelluksissa tarvitaan yleensä useita dokumenttiluokkia, mediaobjekteja, dokumentteja yms. (joiden välillä on riippuvuuksia) 38

è è è Rakenteisten dokumenttien perusteet 2.14 Dokumenttijärjestelmistä Rakenteisia dokumentteja käytetään toki muuhunkin kuin "vain" julkaisemiseen, mutta ideatasolla tästä on hyvä lähteä liikkeelle Pelkistetyn dokumenttijärjestelmän osat: Oma sovellusohjelmointi Dokumenttiprosessori(t) Dokumenttistandardi(t) Tuotantoprosessin suunnittelu- ja hallintavälineet Tyyppimääritystietokanta Dokumenttieditori Objektitietokanta Dokumenttitietokanta Sovellukset (esim. mediakohtaiset ulkoasut) Objekti-editori Parseri (jäsennin ja validaattori) Tyylitietokanta yms. Käytännössä tarvitaan siis 1) standardeja, 2) ohjelmistoja, 3) teknisiä alustoja, 4) menetelmiä sekä 5) oikeita sovelluksia ja käyttötapoja 39

è è è Rakenteisten dokumenttien perusteet 2.15 Aihepiirin käsitteitä (huomaa rajapinnat) Materiaalipankki ~ Esim. tietokantapalvelu johon on talletettu tietyn yhteisön tuottamaa tai hyödyntämää yleiskäyttöistä aineistoa. Mediapalvelin ~ Videon, äänen ja muun (yleensä aikakriittisen) tallenteen jakamiseen soveltuva järjestelmä. Versionhallintajärjestelmä ~ Järjestelmä joka tukee iteratiivista kehitystyötä esim. historiallisen, loogisen ja yhteistoiminnallisen versioinnin keinoin. Sisällönhallintajärjestelmä ~ Yleisnimitys organisaation sisällönhallintaa palvelevasta tietojärjestelmästä (esim. dokumenttienhallintajärjestelmä, wiki, räätälöity tietokantapalvelu tms.; voi sisältää em. järjestelmiä) Projektinhallintajärjestelmä ~ Projektin resurssien, budjetoinnin, tavoitteiden, hakemusten ja aikataulun suunnitteluun käytetty järjestelmä. Asiakastietojärjestelmä ~ Esim. laskutukseen liittyvien perusrekistereiden ylläpito, laskutus, asiakaspalvelutoiminnot, sopimukset sekä raportointi. 40

è è è Rakenteisten dokumenttien perusteet 2.16 Dokumentti- vs. datalähtöinen tiedon mallintaminen Dokumenttilähtöinen mallintaminen jäsentää tiedon kokonaisuuksiksi jolla on tyypillisesti hierarkkinen rakenne - dokumentit muodostavat kokonaisuuksia ja myös näitä käsitellään kokonaisuuksina - esim. Web-sivu, muistio, kirja, vektorikuva Datalähtöinen mallintaminen tarkastelee tietoa "pieninä dokumentteina" (tai tietueina) joita yhdistellään sovelluksessa melko vapaasti - esim. uutistieto, CD-levyn kappaletiedot, yhteystieto, metatieto, viesti Rajanveto on häilyvä; yleensä kyse on tavasta jolla tietoa tuotetaan - "datalähtöisestä" tietoa on periaatteessa helppo poimia dokumenteista - "käsin kirjoitettavaksi" tarkoitettu tieto on yleensä dokumenttilähtöistä ja sovellusalueeltaan melko rajattua (lokaalisti eheä sovellus) - datalähtöistä tietoa käsitellään yleensä hakujen tai loogisesti kuvailtujen prosessien puitteissa (jolloin tietoa tarvitaan esim. tietyn säännön aktivoituessa) (globaalisti eheä sovellus) 41

è è è Rakenteisten dokumenttien perusteet 2.17 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 ja kuka merkkauksen ymmärtää - kuinka 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 toki ole vain staattisten dokumenttien ominaisuus; esimerkiksi yksinkertaiset sähköpostiviestit voidaan koodata tarkkaa SMTPetikettiä (protokollaa) noudattaen (Simple Mail Transfer Protocol) 42

è è è Rakenteisten dokumenttien perusteet 2.18 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> - tehtävä voitaisiin hoitaa (vieläpä paremmin?) myös lähettämällä rakenteisia dokumentteja osapuolten välillä (...Web Services) 43

è è è Rakenteisten dokumenttien perusteet 2.19 "Muuntyyppisiä tietorakenteita kuin dokumentteja" Erotinmerkkeihin perustuvat tekstitiedostot (CSV jne. [,; ]-erotinmerkit): # 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 Track [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 - mallintamisen, käsittelyn ja ohjelmoinnin monimutkaisuus (relaatiot!) - ohjelmallinen käsittely ja std-sovellukset ("hallintajärjestelmät") - haut (kyselykielet), tehokkuus, optimointi, tarvittavat ohjelmat - kysy käsitellä dataa vs. dokumentteja (oliot, ) - pyörän uudelleen keksiminen (toistuvat pulmat: jäsennys, merkkikoodaus, kieli, metatiedot, ohjelmointi,...) 44

è è è Rakenteisten dokumenttien perusteet 2.20 Esimerkki relaatiotietokannan rakenteesta (vertaa!) Peruskäsitteitä: taulu/relaatio, monikko/tietue, mallinnus ja normalisointi, kytkös vs. redundanssi, anomaliat (päivitys, poisto), avaimet, kuuma taulu, optimointi, kysely Artist aid name style a1 Dire Straits rock a2 Pet Shop Boys pop Album rid artist name year r1 a1 Dire Straits 1978 r2 a1 Alchemy 1984 r3 a2 Very 1993 Track tid album name len_ t1 r1 Sultans of Swing 5:34 t2 r1 In the gallery 6:14 t3 r3 Yesterday, when I was mad.? t4 r3 Go West.? 45