Merkkauksen valinnan suunnittelufilosofisia päälinjoja

Transkriptio

1 Merkkauksen valinnan suunnittelufilosofisia päälinjoja Suunnitteluvaiheessa tehty merkkauskäytännön valinta määrää sen, millaista dokumenttien merkkaus tulee olemaan. Sopimaton merkkauskäytäntö hankaloittaa asioita suotta Kannattaa huomata, että "ensin" on sisältö ja rakenne "vasta sitten". "Sisällöllisesti samanlaisiin" dokumenttiluokkiin voidaan yleensä päästä erilaisten "taktisten rakenteellisten" valintojen kautta, joista toiset tyypillisesti "toimivat" paremmin kuin toiset Rakenteiden suhteen joudutaan yleensä suorittamaan "perusvalinta" merkkauksen sisältöspesifisyyden tai pelkän rakenteellisen yhtäläisyyden välillä (esimerkkejä seuraa lisää tuonnempana): - runkona sisällön mukaan nimetyt elementit ([content-based model]) - runkona rakenteen mukaan nimetyt elementit ([structure-based model]) Esimerkki: sisältöspesifisyys vs. geneerisyys <!ELEMENT BOOK (ABSRACT,INTRODUCTION,TERMS,THEORY,MODEL, APPLICATION,REFINEMENT,RESULTS,DISCUSSION,REFS)> <!ELEMENT BOOK (ABSTRACT,SECTION,REFS)> RAKENTEISET DOKUMENTIT (kevät 2000) 308

2 Suunnittelukriteerinä voidaan pitää myös annetun rakenteen jäykkyyttä tai joustavuutta: - (lähes) kaikkien elementtien kirjoittaminen pakollista ([rigid model]) - pakollinen elementtijoukko on pieni ([flexible model]) Esimerkki: jäykkyys vs. joustavuus <!ELEMENT BOOK (ABSRACT,INTRODUCTION,TERMS,THEORY,MODEL, APPLICATION,REFINEMENT,RESULTS,DISCUSSION,REFS)> vs. <!ELEMENT BOOK (ABSRACT,INTRODUCTION?,TERMS?, (THEORY EXAMPLES),MODEL,APPLICATION*, REFINEMENT*,RESULTS,DISCUSSION?,REFS?)> ja jos vapauksia annetaan, kannattaa varmistaa että materiaalintuottajat ja tekniset kirjoittajat eivät mene siitä mistä aita on matalin (terve skeptisyys on kirjoittajien ahkeruuden ja motivoituneisuuden arvioinnissa(kin) paikallaan) Kannattaa kuitenkin muistaa, että rakenteiden jäykkyys voi olla suoraa seurausta suunnittelutyön rajoitteista jotta esim. yhteensopivuus olemassa olevan dokumenttiluokan kanssa voitaisiin varmistetaan (ns. [legacy data]) RAKENTEISET DOKUMENTIT (kevät 2000) 309

3 Tyypillinen tilanne, jossa jäykkyyden ja joustavuuden välille vedetään selkeä raja on päätös mixed/children element content -tyyppisten elementtien mallien välillä Esimerkki: tekstiä ja elementtejä sekaisin vs. mallinnettu elementtirakenne <!ELEMENT PARAG (#PCDATA EM NOTE QUOTE)*> vs. <!ELEMENT PARAG ((EM? (QUOTE,NOTE)?),TEXT)*> <!ELEMENT TEXT (#PCDATA)> Valinta joudutaan tekemään myös metatiedon eksplisiittisen esittämisen ja kokoamisen suhteen: - kerätäänkö metatietoa valmiiksi omiksi elementeikseen ([metadata approach]) - vai koostetaanko metatieto sieltä täältä dokumenttia vasta tarvittaessa ([inline content approach]) Monipuolisen metatiedon kasaaminen tarvittaessa saattaa joidenkin prosessorien tai editorien yhteydessä olla tietenkin myös täysin mahdotonta (tai liian tehotonta), mikä saattaa olla määräävä tekijä valintaa suoritettaessa RAKENTEISET DOKUMENTIT (kevät 2000) 310

4 Esimerkki: metatiedon "isoäiti" päättely vs. julistaminen attribuuttirakenteiden avulla <PERSON NAME="Jack" MOTHER="Jill"/> <PERSON NAME="Jill" MOTHER="Judith"/> vs. <PERSON NAME="Jack" MOTHER="Jill" GRANDMOTHER="Judith"/> <PERSON NAME="Jill" MOTHER="Judith"/> Hierarkkisten elementtirakenteiden syvyyteen joudutaan yleensä ottamaan myös kantaa. Vaihtoehtoja ovat - rekursiiviset elementtimallit ([recursive model]) - lapsielementit luettelevat elementtimallit ([specified model]) Esimerkki: rekursio vs. kiinteä hierarkia <!ELEMENT BOOK (PARA)> <!ELEMENT PARA (PARA CONTENT)> <!ELEMENT CONTENT (#PCDATA)> vs. <!ELEMENT BOOK (PARA1)> <!ELEMENT PARA1 (PARA2)> <!ELEMENT PARA2 (CONTENT)> <!ELEMENT CONTENT (#PCDATA)> RAKENTEISET DOKUMENTIT (kevät 2000) 311

5 Elementeistä, attribuuteista ja rakenteista Dokumenttirakenteita ja erityisesti tietue-elementtejä ("komponentteja, informaatioyksiköitä, komponentteja") suunniteltaessa tyypillinen pulma on tiedon jakaminen järkevästi elementeiksi ja attribuuteiksi Tiedon jakamista XML-attribuuttien ja elementtien välillä käsiteltiin lyhyesti sivuilla Viime kädessä "oikea tapa" ratkaista asia selviää vasta: - merkkauskäytännöstä esitetyistä toiveista (esim. joskus kaikki tieto halutaan esittää elementteinä) - dokumenttien esitysversioiden tuottamiseen liittyvistä rajoitteista (esim. CSS1 ei osaa esittää attribuutteja) - dokumenttiluokan määrittävän skeemaformalismin rajoitteista (esim. XML DTD:n avulla voidaan elementille sallia mv. määrä lapsielementtejä mutta ei attribuutteja) ja siis esimerkiksi XML-spesifikaation piirteistä (esim. parsimatonta dataa käsitellään aina attribuutteihin liitettävien entiteettiviittausten perusteella) - muiden käytettävien ohjelmistojen rajoitteista (esim. ohjelma Z ei osaa käsitellä kaikentyyppistä attribuuttitietoa oikein) RAKENTEISET DOKUMENTIT (kevät 2000) 312

6 Tarkastellaan seuraavaksi tyypillisiä esimerkkitilanteita, joissa vertaillaan yksinkertaisia elementti- ja attribuuttirakenteita Esimerkki: "dokumentissa on erilaisia luetteloita (nimiä, viikonpäiviä, kuukausia), joiden sisältönä on tekstiä" Rakennevaihtoehdot: sisältöspesifi merkkaus vs. yleinen merkkaus 1) 2) PARENT PARENT PARENT PARENT NAME WDAY MONTH Sisältöspesifin merkkauksen hyvänä puolena on rakenteiden selkeys: eri asioille on omat elementtinsä huonoa taas se, että "rakenteen erikoistapauksia" tulee paljon (samanlaisilla rakenteilla on eri nimiä) Yleisen (geneerisen) merkkauksen hyvä puoli on tarpeettoman rakenteellisen toiston karsiminen huonoa taas se, että rakenteiden merkitys ei välttämättä ole suoraan merkkauksesta luettavissa RAKENTEISET DOKUMENTIT (kevät 2000) 313

7 Pelkistetyn (huolimattoman) geneerisen merkkauksen erityisenä vaarana on informaation katoaminen (jos konteksti on tulkinnanvarainen) Tilannetta voidaan selventää rikastamalla rakennetta joko elementtien tai attribuuttien avulla Esimerkki: otsikkokentän lisääminen vs. luokittelu PARENT PARENT TITLE TYPE=(NAME DAY MONTH) Valinta perustuu taas sovelluskohtaisiin suunnitteluratkaisuihin. Tosin yo. tapauksessa attribuutin käyttö on ilmeisen huono ratkaisu, koska tyyppi on selvästikin sekvenssin (listan), eikä sen yksittäisen elementin ominaisuus (nyt sama attribuutti TYPE toistuu turhaan joka elementissä ) Sekvensseille yhteisten ominaisuuksien määrittäminen tapahtuu yleensä luontevimmin (abstraktien) säilöelementtien ([container]) avulla. Ks. tapaus 1 seuraavassa kuviossa: RAKENTEISET DOKUMENTIT (kevät 2000) 314

8 TAPAUS 1: TAPAUS 2: (TIETOA NÄKYVILLÄ ENEMMÄN) PARENT PARENT ID=ID LANG=(FI EN) RESOURCE=NMTOKEN? LIST TYPE=(NAME DAY MONTH) LIST TYPE=(NAME DAY MONTH) TITLE=CDATA ID=ID Elementin ominaisuuksien (attribuuttien) voidaan hyvin ajatella periytyvän puudiagrammin rakenteen mukaisesti elementin jälkeläisille: toistuva attribuuttitieto kannattaa siis merkitä puurakenteessa järkevästi "mahdollisimman ylös" (ks. yo. kuvion tapaus 2) Säiliöelementtien käyttö on erityisen perusteltua tilanteissa, jossa useita sekvenssejä liittyy samaan isäelementtiin Tyypillinen käyttötarkoitus säiliöelementeille on myös tilanne, jossa sekvenssit ovat kokonaan valinnaisia. Puuttuvan sekvenssin tapauksessakin saattaa olla tarkoituksenmukaista korostaa "puuttuvan kohdan rakennetta" RAKENTEISET DOKUMENTIT (kevät 2000) 315

9 Esimerkki: Säiliöelementtien lisääminen on seuraavassa perusteltua sekä rakenteen selkeyttämiseksi että puuttuvan kohdan merkkaamiseksi: PARENT * DESC NAME DAY MONTH MEMO NOTES Nyt on mahdollista, että elementtejä DAY ei ole lainkaan. Jos sen sijaan valitaan PARENT MONTH NAMES DAYS MONTHS * elementti DAYS on "näkyy" vaikka päiviä ei dokumentin esiintymässä olisikaan RAKENTEISET DOKUMENTIT (kevät 2000) 316

10 Säiliöelementit voivat olla luonteeltaan myös "täysin konkreettisia" - tyypillinen (tietokannan) suunnitteluvirhe onkin juuri tyhjien säiliöiden "katoaminen" Esimerkki: seuraavat varastot ovat toki olemassa vaikka ne olisivatkin tyhjiä (varastojen attribuutit tästä selvä merkki - ne voivat esimerkissä tosin puuttuakin) <STOCK> <WAREHOUSE ID="A1" COOLED="NO"> < TYPE="FISH" BOX="PLASTIC-D8" AMOUNT="45"> To be shipped as soon as possible! </> </WAREHOUSE> <WAREHOUSE ID="A2" COOLED="NO"></WAREHOUSE> </STOCK> Oikea malli olisi siis alla tapaus 1) mutta ei tapaus 2) (ei merkkausesimerkkiä): 1) STOCK WAREHOUSE * ID=ID? COOLED=(YES NO) 2) TYPE=(FISH MEAT FRUIT) BOX=NMTOKEN AMOUNT=NMTOKEN STOCK * WH_ID=ID? WH_COOLED=(YES NO) TYPE=(FISH MEAT FRUIT) BOX=NMTOKEN AMOUNT=NMTOKEN RAKENTEISET DOKUMENTIT (kevät 2000) 317

11 Miten kirjoitan hyvän dokumentin tyyppimäärittelyn? Perimmäiset hyvyyden kriteerit ovat tietenkin: 1) DTD toteuttaa määrittelytyön vaatimukset, 2) ratkaisut ovat selkeitä ja käytännössä toimivia DTD on kuitenkin vain osa työn tuloksesta. Hyvän dokumenttiluokan määrittelyn, kun minkä tahansa muunkin spesifikaation, ominaisuuksia ovat: 1) täydellisyys (kaikki asiaankuuluva määritellään ja kuvataan) 2) tarkkuus ja virheettömyys (ei väärinymmärtämisen mahdollisuutta eikä asiavirheitä) 3) ymmärrettävyys (esitys niin yksinkertaisesti ja havainnollisesti kuin mahdollista - sopusoinnussa täydellisyyden ja tarkkuuden kanssa) 4) testattavuus (mahdollisuus verifioida työtä läh. määrityksiin vedoten) 5) jäljitettävyys (mahdollisuus seurata määrityksiä suunnitteluvalintojen kautta toteutukseen ja päinvastoin) Huomaa, että työn loppudokumentoinnin tulisi sisältää teknisen dokumentaation ohella myös seuraavat osat: merkkauksen referenssimanuaali, käyttöohje ja ohjeet eri työkalujen käyttämiseksi RAKENTEISET DOKUMENTIT (kevät 2000) 318

12 Hei, minun nimeni on Ossi. Olen tagien väärinkäyttäjä Hyväkään dokumenttiluokan ja merkkauksen suunnittelu ei auta jos elementtejä merkataan väärin eli vastoin niiden tarkoitusta (vrt. HTML) SGML-maailma tuntee termin TAS: Tag Abuse Syndrome (~tagien väärinkäyttösyndrooma). Väärinkäytön ominaisia piirteitä ovat: 1) tagien valinta niitä vastaavan elementin ulkoasun perusteella (esimerkki: merkataan HEAD3 kun tarkoitetaan vain vahvennettua tekstiä tai kirjoitetaan sivunumero elementin FOOTER sisään, koska näin se saadaan tulosteessa "oikeaan paikkaan") 2) jätetään käyttämättä spesifejä elementtejä kun niitä olisi saatavilla (esimerkki: kirjoitetaan kaikki aineisto elementteihin PARAGRAPH vaikka olisi saatavilla myös elementtejä DEFINITION, EXAMPLE, NOTE ja WARNING) 3) käytetään sekaisin eri merkkausta saman asian esittämiseen (esimerkki: käytetään toisinaan elementtiä QUOTE ja toisinaan EMPHASISED) 4) valitaan merkkaus väärin ymmärtämättä sen merkitystä (esimerkki: merkataan QUOTE kun oikeastaan pitäisi merkata DEFINITION) RAKENTEISET DOKUMENTIT (kevät 2000) 319

13 Tunnistatko omasi? Ongelmat ovat yleensä seurasta Dokumenttiluokan toteuttamisesta - yrityksestä ottaa käyttöön liian laaja tai rikas (l. vaikea) merkkaus - huonosta merkkauksen dokumentoinnista - kiireestä, tietämättömyydestä tai välinpitämättömyydestä - merkkauskäytännön suunnittelu- ja toteutustyön suoranaisista virheistä On tärkeää huomata, että merkkausta pitää opiskella ja harjoitella, koska merkkauskäytäntö on välttämätöntä tuntea kokonaisuudessa etukäteen merkkauksen aloittamista jotta merkkaaminen olisi rikasta ja systemaattista Uudenlaista merkkausta ei opi samalla kun tekee ensimmäistä työtään, vaan se ensimmäinen työ on aina harjoitustyö Hyvään merkkauskäytäntöön päästään yleensä vain riittävän ohjeistuksen ja harjoittelun avulla: - motivointi - riittävä dokumentointi ja käyttöesimerkit - koulutus ja harjoittelu (tämä pitää ottaa huomioon paitsi aikataulussa, myös dokumentaatiossa!) RAKENTEISET DOKUMENTIT (kevät 2000) 320

14 Lopuksi: itsestäänselvyyksiä sikariportaalle TAS on todellinen ongelma, jolta välttäminen vaatii aktiivisia toimenpiteitä sekä työn "tekijältä" että työn "organisoijalta". Jos tiedon merkkaus menee systemaattisesti pieleen, murenee tiedon rakenteellisuuden perusta kokonaan Dokumenttien merkkaaminen käsin ei yleensä ole tarkoituksenmukaista, vaan dokumenttiluokkien käyttö sidotaan yleensä joidenkin (XML-)editorien käyttöön Editorikaan eivät aina poista ongelmia (vaan pahimmillaan muuttavat ne vain toiseen muotoon). Vaikka pitkällä tähtäimellä "rakenteellisuuteen" siirtyminen tehostaisikin työskentelyä, lyhyellä aikavälillä (ylimenokaudella) työmäärä ja tarve uuden opiskeluun kasvaa Rakenteisten dokumenttien suunnittelun tuotosten käyttöönotto synnyttää yleensä muutosvastarintaa, jonka syinä voivat olla esim. - periaatteellinen vastarinta; esim. vastustetaan "ylhäältä valmiina annettua toimintamallia" (vaikka se olisi hyväkin) - lisääntynyt työmäärä, opiskelupaineet, muuttuva työympäristö ja turvallisista (tutuista) ja toimivista toimintamalleista luopuminen, muutosten kerrannaisvaikutukset RAKENTEISET DOKUMENTIT (kevät 2000) 321

15 - uusien ratkaisujen lastentaudit tai kokonaiset suunnitteluvirheet - uusien ohjelmistojen puutteet ja uudenlaiset metaforat Ongelmia voidaan pyrkiä ennaltaehkäisemään ja ratkomaan ennen kaikkea: 1) antamalla kaikille toimijoille vaikuttamisen mahdollisuuksia suunnitteluprosessissa tai vähintäänkin tiedottamalla asioista hyvin 2) huomioimalla "ylimenokausi" resursseissa (koulutuksen järjestäminen ja hyväksymällä väliaikaisesti(?) alentunut työteho) 3) kuuntelemalla kritiikkiä ja muutosehdotuksia sekä kehittämällä työskentelytapoja tämän perusteella (jälkimmäinen unohtuu helposti) Työtapoja suunniteltaessa (ja henkilökuntaa kouluttaessa) kannattaa systemaattisesti pitää kiinni tiedon rakenteistamisen punaisesta langasta. Huonoin toimintamalli on sellainen, jossa kirjoittajat ensisijaisesti muokkaavat dokumenttien esitysversioita ja "päivittävät lähdedokumentteja": "OIKEIN": SISÄLLÖN PÄIVITYKSET LÄHDE- DOKU- MENTTI RENDEROINTI / TRANSFORMOINTI WWW-SIVU PAINOTUOT- TEEN LADONTA "VÄÄRIN": SISÄLLÖN PÄIVITYKSET RAKENTEISET DOKUMENTIT (kevät 2000) 322