Rakenteiset dokumentit, kevät 2006

Transkriptio

1 Johdanto Rakenteiset dokumentit, kevät 2006 MATHM Rakenteiset dokumentit, 6 op, kevään 4-5 periodeilla Kotisivu: Luennot: Harjoitukset: Suoritustapa: KE ja TO 10-12, salissa S2 (poikkeuksia!) TI 10-12, KE ja TO 12-14, salissa Sb204 Luennot, harjoitukset ja tentti. Ei harjoitustyötä. Porkkanapisteitä jaossa. Opettajat: Ossi Nykänen, TD303, vastaanotto to ossi.nykanen@tut.fi, assistentti Ilkka Kaikuvuo, kaikuvuo@cs.tut.fi 1

2 Johdanto 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 (so. käsittely ilman ihmisen käsityötä). Työ nojautuu tietoteknisten välineiden käyttöön. Keskeistä on kyky mallintaa tehtäviä ja tietorakenteita "oikein", eli tarpeet, reunaehdot ja välineiden mahdollisuudet huomioiden. Dokumenttien sijaan tietoa voidaan mallintaa myös datalähtöisesti. Pääpaino on tietenkin sovelluksissa, ei tekniikassa. Laajemmin tarkasteltuna rakenteisen dokumentaation idea tähtää tietojenkäsittelyn prosessien haltuunottoon (käsittelyprosessien abstrahoinnin kautta). Huomattava osa rakenteisten dokumenttien sovelluksista perustuu nykyään erilaisiin XML-tekniikoihin. Laajennettavuutensa ansiosta XML tarjoaa yhteensopivat puitteet mitä moninaisempiin sovelluksiin. 2

3 Johdanto 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

4 Johdanto 1.2 Opintojakson sisältö (1/2) Tällä opintojaksolla "Rakenteiset dokumentit" puhutaan mm. seuraavista asioista: - Tiedon mallinnus sen käsittelyn näkökulmasta - Tieto vs. tietorakenne vs. esitystapa (~rakdok) - Tiedon looginen vs. fyysinen rakenne - Dokumentti- vs. datakeskeinen tieto - Dokumenttistandardit ((X)HTML (aasinsilta)) - XML-dokumentit ja niiden käsittely - XML-dokumentin tyyppi - "XML" vs. XML-standardiperhe - XSL-muunnokset - Sovelluksia ja esimerkkejä, erityiskysymyksiä 4

5 Johdanto 1.3 Opintojakson sisältö (2/2) Kurssilla ei juurikaan (suoraan) puhuta seuraavista: - käyttäjäkeskeisestä suunnittelusta (koska sen pitäisi olla kaiken suunnittelun perusoletus ilman eri mainintaa) - sovellusalueen X erityiskysymyksistä tai yksittäisistä ohjelmistoista (...vaan menetelmistä yleensä) - menetelmien erityiskysymyksistä (...vaan ideoista suodatettuna stdtekniikoihin) - (kovin paljoa) uusien dokumenttiprosessorien toteuttamisesta (...vaan nykyisten soveltamisesta) Opintojakso on perinteinen yo-kurssi - teorialuennot, sovellusluennot, vierailuluennot(?), harjoitukset, lopputentti 5

6 Johdanto 1.4 Opintojakson suoritustapa Arvosanan määrää lopputentti (4 * 6 pts = 24 pts). Hyvää kurssiarvosanaa voi varmistella keräämällä porkkanapisteitä kurssin aikana. Arvosanataulukko on seuraava: arvosana pistemäärä Mikäli porkkanapisteitä on kertynyt edullisesti, huonoimman tenttitehtävän pistesaalis korvataan maksimissaan kuudella porkkanapisteellä. Läpäisyn edellytyksenä on kuitenkin hyväksytty suoritus ilman porkkanapisteitä. Porkkanapisteitä saa tekemällä erikseen merkittyjä harjoitustehtäviä ja osallistumalla aktiivisesti vierailuluennoille. Porkkanapisteiden jakoperuste on opiskelijan oma aktiivisuus ja asioiden opiskelu silloin kun niitä opetetaan. Huom. Porkkanapisteiden lähtökohta on läsnäolo: suorituksia ei saa delegoida toisen merkittäväksi, eikä lähettää sähköpostitse tms. 6

7 Johdanto 1.5 Johdattelevia esimerkkejä rakenteisista dokumenteista (maalaus, näytelmäesitys, eväsretki) piirros, kauppalappu luentomuistiinpano luentopruju artikkeli, runo, näytelmä kirja, kalenteri kuva, audioesitys, animaatio tietokoneohjelman talletustiedosto tekstinkäsittelyohjelman tuottama dokumentti viesti tietokoneohjelmien välillä Hyviä huomioita - tarpeet? käytössä olevat välineet? eri toimijat? ymmärtääkö käsittelijä? tuotannon tehokkuus? käsittelyn tehokkuus? käsittely osissa? - standardit ja siirrettävyys? tiedon uudelleenkäyttö? versiointi ja virkistäminen? lisensointi? sitoutuminen yhteen toimittajaan?... 7

8 Johdanto 1.6 Dokumenttituotannon roolijaosta 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

9 Johdanto 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) - mahdollisuus lopputuloksen näkemiseen jo kirjoitusvaiheessa, joten esimerkiksi pienimuotoinen julkaisutoiminta on mahdollista helposti - mukana monipuolisia formatointi ja taittoominaisuuksia, Internetin myötä myös jakelu Ongelma: työstä tulee helposti käsityötä (suuret dokumentit!) - dokumenttien suunnittelu jää helposti puolitiehen (=tehdään huonosti) - rakenne (rämettyminen) ja kirjoittajan rooli epäselvä (ohjeistus!) Ratkaisuja: hyvä suunnittelu(!), tyylit, etsi/korvaa-toiminnot, mallit, 9

10 Johdanto 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

11 Johdanto 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

12 Johdanto 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 Available at \end{thebibliography} \end{document} 12

13 Johdanto 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

14 Johdanto 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" Käytännössä tämä tarkoittaa sitä, että 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 kyse on aina "painetuksi tarkoitettavien julkaisujen" tekemisestä...entäpä jos halutaan tehdä muuta rakenteellista) WYSIWYG-käyttäjille LaTeX on aluksi "oma maailmansa" -- ideaan joko mieltyy tai sitten ei (nyrkkisääntö: jos kirjoittaa vähän eikä tarvitse esim. kaavoja, Latex tuntuu aluksi "työläältä"). 14

15 Johdanto 1.12 WWW & HTML Internetin suosion myötä tietoverkkojen arvo arkipäiväisen informaation levittelyssä huomattiin. Kirjoittaminen ei vain saisi olla kohtuuttoman vaikeaa World Wide Webin lanseeraama HTML esitteli 90-luvun alussa suurelle yleisölle yksinkertaisen mutta rakenteellisen merkintäkielen - 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 sallivat #%&"-koodit mukisematta - 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...xhtml 15

16 Johdanto 1.13 XHTML-esimerkki Tyypillinen XHTML-tiedosto näyttää seuraavalta: <?xml version="1.0" encoding="iso "?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" " <html xmlns=" <head><title>html-esimerkki</title></head> <body> <h1>johdanto</h1> valitse HTML kun haluat liittää kuvia ja linkkejä websivulle (ja tunnet HTML-merkkauksen perusteet). Esimerkki: <img src="kuva.gif" alt="kuva"/> <a href=" ammattiaineen kotisivut</a> jos et ymmärrä tämän dokumentin merkitystä, käy läpi HTMLkielen perusteet. </body> </html> Huomaa: elementit, erikoismerkit, kommentit sekä dokumentin tyyppi 16

17 Johdanto 1.14 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ä 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?... 17

18 Johdanto 1.15 Mikä WYSIWYG:issä sitten on vikana? Ei niin 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 18

19 Johdanto 1.16 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 ja komponenttiajattelu (dokumenttien peruspalasia ovat elementit, käsittely koostuu vaiheista) - dokumenttien ulkoasun ei ole pakko suoraan vastata niiden 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 SGML:n kehitystyö alkoi jo 1980, pohjana IBM:n GML (Generalized Markup Language) vuodelta 1969! (Goldfarb, Mosher, Lorris) SGML osoittautui kuitenkin varsin raskaaksi isojen poikien standardiksi (esimerkiksi IBM, USA:n Puolustusministeriö) - suppea käyttö ei suosittua 19

20 Johdanto 1.17 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 - tarvitaan 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 - jos valmista sovellusta ei löydy on edessä suunnittelua, opiskelu(!), kirjoittajan roolin muutos(!), "byrokraattisuus/ teknisyys", editorit(!),... XML-standardiperheen ydin tällä hetkellä valmis ja XML:ää tukevien sovellusten kriittinen massa on ylitetty (soveltajia, työkaluja, dataa) 20

21 Johdanto 1.18 Standardiesimerkki rakenteisesta dokumentista looginen rakenne fyysinen rakenne <doc><title> XML 5 vuotta </title> <body> Paljon onnea XML! </body></doc> Sovellus / prosessointi www w3c tut <?xml version= 1.0?> <xsl:stylesheet XML 5 Paljon onnea XML! esitys / näkymä (joskus (kohdedokumentti") rakenteinen (lähde-) dokumentti tyyli (esim. formatointi) kuva (mediaobjekti) 21

22 Johdanto 1.19 Huomioita Aluksi tekniikka vie päähuomion, tietojen ja taitojen karttuessa työ kohdistuu tietoa tuottavien ja hallitsevien prosessien suunnitteluun ja ohjaamiseen Kyse on todellakin enemmänkin juuri suunnittelusta ja prosesseista kuin tekniikoista! - tekniikka X(ML) ei sinänsä ratkaise pulmia vaan tarjoaa välineitä (ja menetelmiä) niiden ratkaisuun (sekä esimerkkejä...) - WYSIWYG ja siihen liittyvät työkalut eivät ole "pahoja" ne sopivat tiettyihin tehtäviin erittäin hyvin (myös esim. MS Wordille on saatavilla hyviä artikkelipohjia yms.) -...itse asiassa ideaalitapauksessa esim. (rakenteinen) sisällöntuotanto piilotetaan WYSWIWYG-tyyppisten työkalujen alle (kun ko. käyttäjäryhmän ei tarvitse ymmärtää koko prosessia) - asiat voi yleensä tehdä useilla eri tavoilla, myös eri tekniikoita käyttäen 22

23 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. Vrt. dokumentin kärjistetty elinkaari: Luonti Muokkaus Tarkastus Hyväksyntä Julkaisu Haku Katselu Arkistointi Kuva: Anttila, 2001 Poisto 23

24 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 tunnistamista ja tietoa välittävien rajapintojen kuvaamista Mekaaniset tehtävät kannattaa yleensä jättää tietokoneiden tehtäväksi 24

25 Rakenteisten dokumenttien perusteet 2.2 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 To: Pentti Pomo Fr: Timo Työmies Uusi tietokantamme on susi! 4) Tulkinta 25

26 Rakenteisten dokumenttien perusteet 2.3 Huomautuksia Ilmeisestikin dokumenttien sisältö, rakenne ja ulkoasu voidaan eriyttää vain jos käytetyt välineet sen sallivat! (tietokoneet!) Tietokoneissa asiasisältö esitetään tietenkin aina suhteessa johonkin tietorakenteeseen 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 (!) 26

27 Rakenteisten dokumenttien perusteet 2.4 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 27

28 Rakenteisten dokumenttien perusteet 2.5 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) 28

29 Rakenteisten dokumenttien perusteet 2.6 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 29

30 Rakenteisten dokumenttien perusteet 2.7 Dokumentin jäsennyspuu (XML) Esimerkki, listarakenne HTML-kielessä <ul lang="en"> <li>dire 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.) 30

31 Rakenteisten dokumenttien perusteet 2.8 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 <div>ks. kuva A1: <img src="a1.png" alt="jalkapallo"/></div> jäsennys  <div>ks. kuva A1: <img alt="jalkapallo" src="a1.png" /> </div> jäsennys 31

32 Rakenteisten dokumenttien perusteet 2.9 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) - nämä ovat asiayhteydestä riippuvia, suhteellisia käsitteitä! d Sovellus / prosessointi d'..... Dokumentti voi olla paitsi staattinen (pysyvä) myös dynaaminen tai virtuaalinen (esim. pyyntöhetkellä ohjeen mukaisesti jäsennetty) 32

33 Rakenteisten dokumenttien perusteet 2.10 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 " %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) 33

34 Rakenteisten dokumenttien perusteet 2.11 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, "esiintymä" (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) 34

35 Rakenteisten dokumenttien perusteet 2.12 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) 35

36 Rakenteisten dokumenttien perusteet 2.13 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 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 36

37 Rakenteisten dokumenttien perusteet 2.14 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) 37

38 Rakenteisten dokumenttien perusteet 2.15 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 toki ole vain staattisten dokumenttien ominaisuus; esimerkiksi yksinkertaiset sähköpostiviestit voidaan koodata tarkkaa SMTPetikettiä (protokollaa) noudattaen (Simple Mail Transfer Protocol) 38

39 Rakenteisten dokumenttien perusteet 2.16 Esimerkki: SMTP-keskustelusta S: MAIL R: 250 OK S: RCPT R: 250 OK S: RCPT R: 550 No such user here S: RCPT 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) 39

40 Rakenteisten dokumenttien perusteet 2.17 "Muuntyyppisiä tietorakenteita kuin dokumentteja" Erotinmerkkeihin perustuvat tekstitiedostot (CSV jne.): # seuraavat ovat kappaleiden tietoja Sultans of swing 3: Dire Straits Dire Straits Yesterday, When I Was Mad 3: Very Pet Shop Boys Relaatiotietokannat (esim. taulu tai relaatio Track [tyyppitiedot!]): name len year album artist Sultans of swing 3: Dire Straits Dire Straits Yesterday, When I Was Mad 3: 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,...) 40

41 Rakenteisten dokumenttien perusteet 2.18 Esimerkki järkevän relaatiotietokannan rakenteesta 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.? 41

42 XHTML-dokumenttien anatomia 3 XHTML-dokumenttien anatomia XHTML tarjoaa tutun esimerkin rakenteisten dokumenttien opiskelun alkutaipaleelle. Erityisesti, koska XHTML on XML-sovellus: - havainnollistaa se tiedon teknistä merkkausta (merkkauskielioppi), - osoittaa merkkauksen ja dokumentin tyypin välisen suhteen, sekä - tarjoaa esimerkin erään dokumenttiluokan suunnittelusta....ainakin periaatteessa. Käytännössä, eri syistä johtuen, kaikki XHTMLsovellukset (esim. verkkoselaimet) eivät toteuta kaikkia XML:n edellyttämiä piirteitä, vaikka tästä olisikin soveltajalle melkoista hyötyä 42

43 XHTML-dokumenttien anatomia 3.1 Varoitus! XHTML ei ole rakenteisten dokumenttien "maali", vaan nyt "vain" hyvä opiskelun lähtökohta koska kielen sovellukset ja idea oletetaan periaatteessa tunnetuksi 95% Web-sivuja joskus tehneistä ei kuitenkaan osaa XHTML-kieltä eikä sen merkkausta pintaa syvemmältä...suhtaudu siis tähän(kin) aiheeseen vakavissasi, vaikka olisitkin sitä mieltä että osaat jo HTML-kielen "varsin hyvin" 43

44 XHTML-dokumenttien anatomia 3.2 Esimerkki: XHTML-dokumentti XHTML-dokumentti on XML-dokumentti joka rakenteellisesti noudattaa tiettyä dokumentin tyyppimääritystä (DTD),..joka kirjoitetaan tyyppiesittelynä (tai -deklaraationa) <?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> check <a href=" </body> </html>  XML "näkyy läpi" XHTML-sanaston pohjalla: fyysinen ja looginen rakenne (tiedosto ja elementit), kommentit yms., nimiavaruuden käsite, jne. XHTML-dokumentin kirjoittajan ei tarvitse tietää "kaikkea" XML:stä 44

45 XHTML-dokumenttien anatomia 3.3 Hypertext Markup Language, HTML HTML on tarkoitettu verkkosivujen sisällön kuvailemiseen, tehtävä on: - sisällön loogisen rakenteen kuvailu (ulkoasu on sovelluksen heiniä) Useita suosituksia (ks. - vanhat HTML-versiot (2.0, 3.2) ja HTML XHTML-perhe - XHTML 1.0 The Extensible HyperText Markup Language (Second Edition) (Kolme versiota: Strict - Transitional - Frameset) - Modularization of XHTML - XHTML Module-based XHTML - XHTML Basic - Suositus "XHTML 2.0" kehitteillä Huom! (X)HTML on "vain julkaisuformaatti" ja hyvin rajoittunut sellainen 45

46 XHTML-dokumenttien anatomia 3.4 XHTML Basic, se pieni & järkevä XHTML-sanasto XHTML Basic määrittelee HTML:n kuvailevan ytimen Rajaus ja moduulijako on hyödyllinen, vaikkei kirjoittaisi varsinaisesti XHTML Basic - dokumentteja Jatkossa XHTML kehittynee entistä selvemmin juuri moduulien suuntaan - yhdisteltävyys ja profilointi - XML-tekniikoiden hyödyntäminen 46

47 XHTML-dokumenttien anatomia 3.5 XHTML-dokumenttityypin määrittely XHTML (DTD HTML 1.0 Strict) -tyyppisten dokumenttien elementtirakenne kerrotaan tyyppimäärityksessä formaaleina sääntöinä (ja sekä tarvittaessa esim. sanallisina rajoitteina), vrt. <!ELEMENT img EMPTY> <!ATTLIST img %attrs; src %URI; #REQUIRED alt %Text; #REQUIRED longdesc %URI; #IMPLIED height %Length; #IMPLIED width %Length; #IMPLIED usemap %URI; #IMPLIED ismap (ismap) #IMPLIED > Määritys kertoo asiat formaalin kielen (so. tietorakenteen) näkökulmasta, merkitys ja käyttö pitää tietenkin ohjeistaa muutenkin! 47

48 XHTML-dokumenttien anatomia 3.6 XHTML-dokumentin esittelyosa <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" " Huomautuksia - kertoo dokumentissa käytetyn XML-standardin version (nyt 1.0) sekä mahdollisesti tekstitiedoston merkkikoodauksen (+ muutakin) - kertoo dokumentin tyypin (nyt DTD XHTML 1.0 Strict) Huom. XML-standardin mukaan, esittelyosa voisi sisältää myös muitakin osia, esim. sisäisen DTD-osajoukon, vrt. dokumentin paloittelu <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" " [ <!ENTITY copy_decl SYSTEM "copy.txt"> ]> 48

49 XHTML-dokumenttien anatomia 3.7 XHTML-dokumentin esiintymäosa <html xmlns=" xml:lang="en" lang="en"> <head> <title>virtual Library</title> </head> <body> check <a href=" </body> </html> Kertoo oleellisesti dokumentin asiasisällön - yksikäsitteinen juurielementti (nyt html; vrt. tyyppiesittely) - aidosti sisäkkäinen elementtirakenne - XHTML-dokumentissa pitää kertoa myös dokumentin nimiavaruus Dokumenttiluokkakohtainen rakenne määräytyy dokumentin tyypin mukaan (tai sitten dokumentti on "virheellinen", ts. ei ole validi) - esim. XHTML-dokumentissa aina head- ja body-osat, nimi title tarkoittaa head-osassa pakollista elementtiä tai "useimpia" elementtejä kuvailevaa attribuuttia jne. 49

50 XHTML-dokumenttien anatomia 3.8 Elementtien merkkaaminen Elementti merkitsee nimetyn tekstilohkon (on myös nimettömiä!) - voi sisältää merkkidataa ja toisia elementtejä (rekursio määritelmässä) - voi myös sisältää muitakin merkkausrakenteita (esim. kommentteja) - sovellus päättää tyhjämerkkien tulkinnan - alkutagi, elementin nimi, sisältö, lopputagi, tyhjän elementin tagi <head>  <title>musiikkityyleistä</title> <link rel="stylesheet" type="text/css" href="music.css" /> </head> Tiedon mallintamisen perusidea: "elementit esittävät konkreettisia asioita, joille attribuutit antavat abstrakteja määreitä" - DTD sanoo mitkä nimet ja rakenteet nyt sallittuja, isot ja pienet kirjaimet merkitseviä, useita merkkaustapoja (muttei lyhennemerkintöjä) Huom. elementtien merkkaus varaa käyttöönsä erikoismerkin '<' 50

51 XHTML-dokumenttien anatomia 3.9 Erikoismerkeistä: entiteetit ja merkkiviittaukset Koska merkki '<' on tietenkin tarpeellinen myös asiasisällössä, pitää vastaava merkki pystyä liittämään dokumenttiin merkkauksen avulla, esim. entiteettiviittauksena HTML määrittelee suuren joukon vakioentiteettejä, mm. < ~ < > ~ > & ~ & " ~ " (vaikkei HTML määrittele, sanotaan jo nyt että ' ~ ') Entiteettiviittauksen saa kirjoittaa sinne minne merkkausta voi kirjoittaa (ts. elementit ja attribuutit) Yksittäisiä merkkejä voi liittää dokumenttiin myös merkkiviittausten avulla A ~ A 51

52 XHTML-dokumenttien anatomia 3.10 Attribuuttien merkkaaminen Elementin alkutagi (tai tyhjän elementin tagi) voi sisältää attribuutteja - attribuutin nimi ja arvo erotetaan '='-merkillä, arvo ympäröidään heitto- tai lainausmerkein, sovellus päättää tyhjämerkkien tulkinnan (ns. normalisointi attribuutin tyypin mukaan) - attribuutin arvo voi sisältää tekstiä (jossa siis voi esiintyä entiteetti- ja merkkiviittauksia) - attribuuteilla ei ole loogista järjestystä, attribuutti ei saa toistua <a href="list.php?id=1&cmd='a b'" title="listaus">l1</a> Attribuutit esiintyvät aina suhteessa elementteihin Huomionarvoisia attribuutteja: - id, href, lang, xml:lang, xml:space 52

53 XHTML-dokumenttien anatomia 3.11 Muu merkkaus: kommentit Koska kyse on XML-dokumentista, XHTML-dokumentista voi löytyä myös muita merkkausrakenteita, nimittäin - kommentteja - (sekä prosessointiohjeita ja merkkidatalohkoja; nämä sivuutamme toistaiseksi) Kommentti on yleensä merkkaajan oma muistiinpano, mutta saattaa välittyä myös lukijoille (sovelluksesta riippuen)  Huom. Kommentit ovat osa merkkausta ja voidaan siten jäsentää loogisena osana dokumentin asiasisältöä (!), X(HT)ML ei salli sisäkkäisiä kommentteja (!), eikä merkkijonoa "--" 53

54 XHTML-dokumenttien anatomia 3.12 HTML:n kehityksestä ja merkkauksesta (1/2) XHTML on kehittynyt rakenteiseksi dokumenttistandardiksi ajan kuluessa - esim. DTD XHTML 1.0 Strict rajaa laajemmasta (Transitional) sanastosta pois formatointiin liittyviä piirteitä (esim. elementti font) Motivaatio on se, että XHTML-dokumenteilla ja esim. CSS-tyyleillä on selvä työnjako: - XHTML sisältää dokumentin asiasisällön kuvailevan tai deskriptiivisen merkkauksen keinoin, joka kertoo mitä loogisia osia dokumentista löytyy sen asiasisällön näkökulmasta - käytännössä CSS-tyyli formatoi dokumentin, ehdottaen fontit, värit, vahvennukset, jne. Kuvaileva merkkausta pidetäänkin yleensä formatoivan merkkauksen vastakohtana (tarkka rajanveto hankalaa; suhteessa tiettyyn sovellukseen) 54

55 XHTML-dokumenttien anatomia 3.13 HTML:n kehityksestä ja merkkauksesta (2/2) Miksi pyrkimys deklaratiiviseen merkkaukseen? Hallittavuuden takia: koska... - (lähde)dokumentti voidaan mallintaa sovellusalueen luonnollisten käsitteiden näkökulmasta (nyt XHTML ~ WWW-hypertekstin julkaisukieli); tästä on hyötyä myös kirjoittamisen ja käsittelyn työnjaon näkökulmasta - sama sisältö voidaan tuotantoprosessin keinoin esittää eri tavoin (vrt. WWW-sivu [pc pda], paperituloste, PDF-sivu) -...ts. dokumenttien asiasisältö ja ulkoasu voidaan erottaa prosessoinnissa, nojautuminen formatointiin johtaa helposti informaation katoamiseen tietoa merkatessa (esim. tiedonhaku) 55

56 XHTML-dokumenttien anatomia 3.14 Rakenteiden merkitsemistapoja ja termejä (1/3) Hierarkkiset elementtirakenteet ~ sisäkkäisiä elementtimäärityksiä, joiden jäsentäminen tuottaa elementtien puurakenteen (properly nesting elements) Limittäiset lohkorakenteet ~ "päällekkäisiä rakennemääritelmiä", jotka eivät (välttämättä) määritä selvärajaisia elementtejä fat and lean fat and lean  Limittäisiä lohkorakenteita käytetään toisinaan esim. hakujen ja dokumenttien elementtirajat ohittavan annotoinnin takia (ei suositeltavaa); ... Dire straitsin <revision/> pitkäsoitto dire Straits: <revisionend/>dire Straits ilmestyi jo Hierarkkisuuden keskeisin etu on rakenteen selkeys käsittelyn näkökulmasta 56

57 XHTML-dokumenttien anatomia 3.15 Rakenteiden merkitsemistapoja ja termejä (2/3) Deklaratiivinen tai kuvaileva merkkaus ~ abstrakti kuvaus elementin roolista tai merkityksestä dokumentissa (siis juuri XHTML:n idea) <blockquote>think twice before walking on ice</blockquote>  Proseduraalinen tai spesifi merkkaus ~ tarkat ohjeet elementtien käsittelemiseksi tietyssä yksittäisessä sovelluksessa (tyypillinen juuri formatoinnissa) Think twice before walking on ice  Erittäin hyviä huomioita: - dokumentin (1) perusteella on paljon helpompi mekaanisesti tuottaa dokumentti (2) kuin päinvastoin -...ts. "abstrakti" (1) tavoittaa tekstinpätkän merkityksen jotenkin "osuvammin ja niukemmin" kuin "konkreettinen" tai "sovelluskohtainen" (2) - tapa (2) on huono myös koska muukin kuin blockquote-tyyppinen tieto formatoidaan kenties i- ja font-elementein (..."tietoa hukkuu vahingossa") 57

58 XHTML-dokumenttien anatomia 3.16 Rakenteiden merkitsemistapoja ja termejä (2/3) Kontekstivapaa merkkaus ~ naapurielementit eivät vaikuta tulkintaan (löyhästi ymmärrettynä) fat and lean Kontekstuaalinen merkkaus ~ elementtien tulkinnalla on jokin tietty rakenteesta riippuva konteksti <ul> <li>yksi</li> <li>kaksi</li> <li>kolme</li> </ul> Kontekstivapaan merkkauksen verraton etu on tulkinnan helppous sekä mahdollisuus paloitella dokumentti melko vapaasti Kontekstuaalisen merkkauksen edut liittyvät lähinnä mallintamiseen (esim. attribuuttitieto voi periytyä elementin jälkeläisille, mikä vähentää esim. merkkaustyötä) 58

59 XHTML-dokumenttien anatomia 3.17 Pari sanaa CSS-tyylikielestä Kuten tunnettua Cascading Stylesheets (CSS) on tyylikieli esim. XHTMLsivujen ulkoasun määrittämiseen. Se määrittelee mm. - (formatointimallin, mediaryhmiä,...) - formatointiominaisuuksia sekä kieliopin tyylisääntöjen esittämiseen. Vaikka CSS on verraten rajoittunut tyylikieli, jo CSS-säännöt havainnollistavat XHTML-dokumentin loogisen rakenteen merkitystä konkreettisesti, vrt. seuraavien sääntöjen tulkinta: body { color: red; } p img.diagram { border: 1px solid black; } 59

60 XHTML-dokumenttien anatomia 3.18 CSS2-valitsimet pähkinänkuoressa Tässä vaiheessa on hyvä miettiä lähinnä sitä, minkälaisiin loogisiin rakenteisiin ao. valitsimet pystyvät viittaamaan X(HT)ML-dokumenteissa... (tietorakenteisiin viittaaminen on tiedonkäsittelyn perusta) * Matches any element. Universal selector E Matches any E element (i.e., an element of type E). Type selectors E F Matches any F element that is a descendant of an E element. Descendant selectors E > F Matches any F element that is a child of an element E. Child selectors E:first-child Matches element E when E is the first child of its parent. The :first-child pseudo-class E:link E:visited Matches element E if E is the source anchor of a hyperlink of which the target is not yet visited (:link) or already visited (:visited). The link pseudo-classes 60

61 XHTML-dokumenttien anatomia E:active ja E:hover ja E:focus Matches E during certain user actions. The dynamic pseudo-classes E:lang(c) Matches element of type E if it is in (human) language c (the document language specifies how language is determined). The :lang() pseudo-class E + F Matches any F element immediately preceded by an element E. Adjacent selectors E[foo] Matches any E element with the "foo" attribute set (whatever the value). Attribute selectors E[foo="warning"] Matches any E element whose "foo" attribute value is exactly equal to "warning". Attribute selectors E[foo~="warning"] Matches any E element whose "foo" attribute value is a list of space-separated values, one of which is exactly equal to "warning". Attribute selectors E[lang ="en"] Matches any E element whose "lang" attribute has a hyphen-separated list of values beginning (from the left) with "en". Attribute selectors DIV.warning HTML only. The same as DIV[class~="warning"]. Class selectors E#myid Matches any E element ID equal to "myid". ID selectors 61

62 XHTML-dokumenttien anatomia 3.19 Huomautuksia Kuten esimerkeistä kävi ilmi (?), XHTMLdokumenttien tekninen merkkaus on verraten yksinkertaista Haasteita syntyy lähinnä - "mallintamisesta", ts. nyt kyvystä kuvailla valittu tietosisältö XHTML-dok. tyypin mukaan niin rikkaasti kuin tarpeen (erit. elementit div, span ja class-attribuuttien käyttö?) - sovelluksista, esim. tyylien kirjoittamisesta (esim. CSS2-säännöt ovat monimutkaisempia kuin itse elementtirakenteet [esim. "seuraava sisar"]) Ts. haaste ei ole se miten merkataan, vaan mitä merkataan ja miksi Huom. dokumenttien validointikaan ei tietenkään takaa että tieto on asiasisällöllisesti virheetöntä merkkauksen sisällölliset virheet tietenkin kaivavat maata rakenteisten dokumenttien alta (kun ei tulkintaa!) 62

63 XHTML-dokumenttien anatomia 3.20 Hei, minun nimeni on Ossi. Olen tagien väärinkäyttäjä SGML-maailma tuntee leikkimielisen termin TAS: Tag Abuse Syndrome (~tagien väärinkäyttösyndrooma). "Väärinkäytön" ominaisia piirteitä ovat: 1) elementin valinta sen ulkoasun perusteella sovelluksessa (esimerkki: merkataan h3 kun tarkoitetaan vain "vahvennettua tekstiä") 2) jätetään käyttämättä spesifejä elementtejä kun niitä olisi saatavilla (esimerkki: kirjoitetaan kaikki aineisto p-elementteihin vaikka olisi käytössä myös elementit dfn, kbd, ja code) 3) käytetään sekaisin eri merkkausta saman asian esittämiseen (esimerkki: käytetään toisinaan elementtiä blockquote ja toisinaan em) 4) valitaan merkkaus väärin ymmärtämättä sen merkitystä (esimerkki: merkataan dfn kun "tarkoitettiin" var) Tunnistitko omasi? Pulmat ovat yleensä seurasta merkkauksen monimutkaisuudesta, vähäisestä koulutuksesta tai välinpitämättömyydestä 63

64 XHTML-dokumenttien anatomia 3.21 Lopuksi Myös XHTML-osaamista tarvitaan käytännössä tälläkin kurssilla...mutta osana tuotantoprosessia! Useissa sovelluksissa XHTML on julkaisuformaatti (tulosdokumentteja) joka tuotetaan ohjelmallisesti esim. muunnostyyleillä sovelluksen tietomallin perusteella, ei suoraan nodepadilla kirjoittamalla (!!) Ei-triviaalien Web-palvelujen koodaaminen XHTML-käsityönä on useimmissa tapauksissa lyhytnäköistä (turhaa käsityötä, virhealtista, tulos on heikosti hallittavissa, jne.) 64