2 Rakenteisten dokumenttien perusteet

Transkriptio

1 è è è 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,

2 è è è 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 25

3 è è è Rakenteisten dokumenttien perusteet 2.2 Mikä on rakenteinen dokumentti? Rakenteinen dokumentti ~ rakenteellinen dokumentti ~ dokumentti, jossa erotetaan toisistaan dokumentin a) sisältö, b) yleiskäyttöinen rakenne ja c) ulkoasu (tai esitystapa) 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 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 Muistio To: Pentti Pomo Fr: Timo Työmies Uusi tietokantamme on susi! 4) Tulkinta / Käyttö sovelluksessa 26

4 è è è 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 (!) 27

5 è è è Rakenteisten dokumenttien perusteet 2.4 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 28

6 è è è Rakenteisten dokumenttien perusteet 2.5 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) - 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. itsensä 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) 29

7 è è è 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 30

8 è è è Rakenteisten dokumenttien perusteet 2.7 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" aina vain ohjelmointirajapinnan 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.) 31

9 è è è 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 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 32

10 è è è Rakenteisten dokumenttien perusteet 2.9 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) 33

11 è è è 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) Dokumenttilähtöisessä tiedon mallinnuksessa luonnollinen tulkinta on yleensä "rajaavampi" kuin datalähtöisessä tiedon mallinnuksessa 34

12 è è è 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/sovelletaan 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ä (Esim. XML DTD, XML Schema ja Schematron) (DTD = Document Type Definition, dokumentin tyyppimääritys) 35

13 è è è 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) 36

14 è è è Rakenteisten dokumenttien perusteet 2.13 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: 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 37

15 è è è 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) 38

16 è è è 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) 39

17 è è è 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) 40

18 è è è 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,...) 41

19 è è è Rakenteisten dokumenttien perusteet 2.18 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.? 42

20 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ä 43

21 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" 44

22 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> <p>check <a href=" </body> </html> <!-- Mod. --> 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ä 45

23 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 46

24 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 47

25 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! 48

26 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"> ]> 49

27 3.7 XHTML-dokumentin esiintymäosa <html xmlns=" xml:lang="en" lang="en"> <head> <title>virtual Library</title> </head> <body> <p>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. 50

28 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> <!-- HTML-dokumentin otsikko-osa --> <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 '<' 51

29 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ä &apos; ~ ') Entiteettiviittauksen saa kirjoittaa sinne minne merkkausta voi kirjoittaa (ts. elementit ja attribuutit) Yksittäisiä merkkejä voi liittää dokumenttiin myös merkkiviittausten avulla A ~ A 52

30 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 53

31 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) <!-- Pitäisikö tämä luku poistaa? ( :ON) --> 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 "--" 54

32 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) 55

33 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) 56

34 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ä <b>fat</b> <i>and</i> <i><b>lean</b></i> <b>fat</b> <i>and <b>lean</i></b> <!-- ei siis XHTML-merkkausta! --> Limittäisiä lohkorakenteita käytetään toisinaan esim. hakujen ja dokumenttien elementtirajat ohittavan annotoinnin takia (ei suositeltavaa); <p>... Dire straitsin <revision/> pitkäsoitto <em>dire Straits: <revisionend/>dire Straits</em> ilmestyi jo </p> Hierarkkisuuden keskeisin etu on rakenteen selkeys käsittelyn näkökulmasta 57

35 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> <!-- (1) --> Proseduraalinen tai spesifi merkkaus ~ tarkat ohjeet elementtien käsittelemiseksi tietyssä yksittäisessä sovelluksessa (tyypillinen juuri formatoinnissa) <i><font face="arial" size="12"> Think twice before walking on ice</font></i> <!-- (2) --> 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") 58

36 3.16 Rakenteiden merkitsemistapoja ja termejä (2/3) Kontekstivapaa merkkaus ~ naapurielementit eivät vaikuta tulkintaan (löyhästi ymmärrettynä) <b>fat</b> <i>and</i> <i><b>lean</b></i> 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ä) 59

37 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; } 60

38 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 61

39 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 62

40 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!) 63

41 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 "korostettua 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ä 64

42 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.) 65