2.17 Esimerkki järkevän relaatiotietokannan rakenteesta

Transkriptio

1 Rakenteisten dokumenttien perusteet 2.17 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.? 37

2 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ä 38

3 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) lukuun vakavissasi, vaikka olisitkin sitä mieltä että osaat jo HTML-kielen "varsin hyvin" 39

4 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ä 40

5 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 41

6 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 42

7 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, informaaleina 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! 43

8 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"> ]> 44

9 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. 45

10 3.8 Elementtien merkkaaminen Elementti merkitsee tekstilohkon - 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 '<' 46

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

12 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 48

13 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 "--" 49

14 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) 50

15 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) 51

16 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 52

17 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") 53

18 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 mielekkäästi Kontekstuaalisen merkkauksen edut liittyvät lähinnä mallintamiseen (esim. attribuuttitieto voi periytyä elementin jälkeläisille, mikä vähentää esim. merkkaustyötä) 54

19 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; } 55

20 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 56

21 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 57

22 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!) 58

23 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ä 59

24 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.) 60