12 Dokumenttiluokan toteuttamisesta Tyypillisiä XML-sovellutuksia ovat esimerkiksi: - annettuun käyttötarkoitukseen räätälöity dokumenttityyppi (esim. painotalon ABC malli käsikirjoituksen rakenteelle) - helppokäyttöinen, yhteensopiva ja muokattava tietorakenne (esim. ohjelman DEF talletustiedosto) - tietokannan GHI raporttitiedosto (joka esim. esitetään assosioimalla se valitun tyylimäärityksen kanssa asiakkaan selaimessa) Yhteistä näille on se, että viime kädessä XML-spesifikaation näkökulmasta niissä kaikissa on kyse jonkin tietyn dokumenttiluokan dokumenttien käsittelystä Lähes kaikille XML-sovellutuksille on yhteistä myös se, että niitä ei tehdä "XML:llä yksin XML:n takia", vaan koska - omassa sovelluksessa halutaan käyttää (jonkun muun suunnittelemaa) hyväksi havaittua dokumenttiluokkaa A - dokumenttien rakenne halutaan tarkastaa tai validoida parserilla B 73275 RAKENTEISET DOKUMENTIT (kevät 2003) luentorunko ON 269
- dokumentteja halutaan välittää ohjelmien tai yhteisöjen C ja D välillä - dokumentteja halutaan katsella (prosessoida) ohjelmalla E - halutaan saada käyttöön XML-editori F, jne. Käytännössä tämä tarkoittaa sitä, että järkevän dokumenttiluokan suunnittelussa on kyse paljon enemmästä kuin vain merkkausdeklaraation suoltamisesta - kyse on siitä että - miten asiat kannattaisi määritellä & tehdä kun sovelluskenttä on tiedossa? - miten toiveet käytännössä voidaan pusertaa (esim.) DTD:n muotoon? Halutun dokumenttiluokan "tekeminen" tapahtuu "hyväksi havaitun käytännön" mukaisesti sisältäen esim. seuraavat vaiheet: a) esitutkimus (mitä tehdään/onnistuuko edes/mitä pitää tietää) b) määrittely (mitä ajetaan takaa/oleelliset tavoitteet) c) suunnittelu (miten tavoitteeseen päästään) d) toteutus (deklaraatioiden kirjoittaminen ja dokumentointi) e) testaus (toimiiko todella kuten ajateltiin/otetaanko käyttöön) 73275 RAKENTEISET DOKUMENTIT (kevät 2003) luentorunko ON 270
Dokumenttiluokan suunnittelu- ja kehitystyö vastaa siis itsessään suuresti dokumentaatioprosessia (pohjimmiltaanhan kyse samantyyppisestä asiasta) Pienissä sovellutuksissa vaiheet yleensä sulautuvat toisiinsa, eikä työn "muodollisista" vaiheista juuri välitetä. Systemaattisuuteen ja työvaiheiden tulosten selkeään kirjaamiseen on kuitenkin syytä kiinnittää erityistä huomiota (viimeistään) kun: - tilaus työlle tai tavoitteet tulevat työryhmän ulkopuolelta - työn asiasisältö tai tekemisen vastuualueet eivät ole kaikille tekijöille "itsestään selviä" - tekijätiimin koko kasvaa yli kolmen tai tekijät eivät työskentele "samassa tilassa" - tekijätiimin jäsenten osaamisalueet ovat selkeästi erilaisia - työn toteutuksen odotetaan kestävän yli viikon - joku muu käyttää työtä oman työnsä pohjana XML-sovellusten suunnitteleminen ei oleellisesti eroa muusta suunnittelu- ja toteutustyöstä myöskään siinä että: 73275 RAKENTEISET DOKUMENTIT (kevät 2003) luentorunko ON 271
- hyvä XML-spesifikaation (ja menetelmien) "tekninen" osaaminen ei pelasta suunnittelutyötä, mikäli sovellusalueen "sisällön" tuntemus on suunnittelijoilla heikkoa - mutta sopimattomat tekniset ratkaisut (ja XML:n ominaispiirteiden heikko tuntemus) saattavat "muuten hyvänkin" suunnitelman pilata (tai ainakin asettaa sille epärealistisia odotuksia) Käytännössä tämä tarkoittaa sitä, että sovelluksen Y suhteen pitää tietää mitä ollaan tekemässä, kenelle, miksi ja millä eväillä: 1) mihin sovellusta on tarkoitus käyttää ja mitä hyötyä XML:stä tässä yhteydessä on (tai uskotaan olevan)? 2) mihin olemassa oleviin järjestelmiin (tai dokumenttien tyyppimäärityksiin) ollaan sitoutumassa (tai kannattaisi sitoutua) ja mitä rajoituksia tai etuja tämä antaa suunnittelu- ja kehitystyölle (ja jatkossa käytölle)? 3) kuka tai mikä sovellusta käyttää ja miten ja kuinka tämä kaikki pitää ottaa huomioon dokumenttiluokan suunnittelussa, määrittelyssä, dokumentoinnissa, ohjeistuksessa (koulutuksessa) ja jatkokehityksessä? 4) kuinka paljon (ajallisia ja rahallisia) resursseja suunnittelu- ja kehitystyöhön on käytettävissä? Onko esim. omien editorien toteuttaminen mahdollista? 73275 RAKENTEISET DOKUMENTIT (kevät 2003) luentorunko ON 272
Puhtaasti XML 1.0:n näkökulmasta kysymykset kuitenkin pelkistyvät muotoon: "millaisia XML-dokumentteja sovelluksessa Y tarvitaan tai kannattaisi käyttää?" Tällöin dokumenttiluokan suunnitteleminen tarkoittaa konkreettisena toimenpiteenä dokumenttiluokan suunnittelemista, toteuttamista (esim. DTD:nä), dokumentoimista ja käytön ohjeistamista On kuitenkin syytä muistaa, että samalla tavalla kuin ohjelmointi (~"suorittavaa työtä") on vain osa ohjelmiston kehittämistyötä (~"suunnittelu- ja organisointityötä"), on dokumentin tyyppideklaraation kirjoittaminen vain osa dokumenttijärjestelmän kehitystyötä. Osa, johon ei tule ryhtyä liian varhain käytännössä ohjelmoinnista ja deklaraatioiden kirjoittamisesta kuitenkin puhutaan suunnittelua enemmän - syy on yleensä se, että näiden järkevä ohjeistaminen on yleisessä tapauksessa "helpompaa" tai "hyödyllisempää" Seuraavassa tarkastellaan lähinnä niitä (yksinkertaisia ja) konkreettisia menetelmiä, joita suunnittelutyöhön voidaan käyttää On ilmeistä, että halutun dokumenttiluokan suunnittelu, jatkuva testaus, ohjelmistovalinnat jne. kannattaa tehdä yhteistyössä sisällöntuottajien ja työn soveltavien tahojen kanssa (jos sellaisia on), käyttäjien taitotaso ja annettujen ohjelmistojen rajoitteet (yms.) huomioiden. Niinpä näistä asioista ei jatkossa joka yhteydessä enää erikseen mainita. 73275 RAKENTEISET DOKUMENTIT (kevät 2003) luentorunko ON 273
Kaiken suunnittelun kulmakivi: luova kokeileminen Suoraviivainen tapa lähteä liikkeelle dokumenttiluokan suunnittelussa on kirjoittaa kokeilumielessä halutuntyyppisiä (pienimuotoisia ja selkeitä) XMLdokumentteja (ilman dokumentin tyyppideklaraatiota): - perus"käsitteiden" tunnistaminen ja abstrahointi (elementtihierarkian pääpiirteiden suunnittelu mutta myös rakenteiden rajoittaminen) - geneeristen rakenteiden tunnistaminen (jos niitä oikeasti on) - elementtien tunnistaminen ja nimeäminen - keskustelun herättäminen suunnittelutiimin keskuudessa ja ideointi Elementtirakenteita suunniteltaessa kannattaa pitää sopiva tasapaino merkkauksen helppouden ja (sisällöllisen ja rakenteellisen) metatiedon määrän suhteen: - on totta, että yleisesti pätee: "mitä rikkaampi rakenne, sen parempi" - MUTTA: mitä välttämättä tarvitaan? onko esim. metatietoa oikeasti runsaasti saatavilla, mistä se tulee ja tullaanko kaikki annetut täyttämään kentät systemaattisesti ja relevantilla tiedolla (onko mahdollista)? 73275 RAKENTEISET DOKUMENTIT (kevät 2003) luentorunko ON 274
Rakenteiden mutkikkuudessa, elementtien nimeämisessä yms. kannattaa myös etukäteen miettiä kuka elementit kirjoittaa ja millä: - tuottaako dokumentin joku käsin notepadilla, erikoistuneella XMLeditorilla, sovelluksella Z (tietämättä että tiedot talletetaan XMLmuodossa) vai tuotetaanko dokumentit aina tietokoneohjelman toimesta - onko dokumentteja tarkoitus myös lukea "sellaisenaan" Esimerkki; täyttäisitkö sinä seuraavan elementin kaikki attribuutit huolella ja ajatuksella aina käsin notepadilla jos elementtejä tulisi kirjoittaa n. 100 per dokumentti: <CHAPTER EDITOR="ON" ORG="TUT/DMI" LASTMOD="13.3.2000" KEYWORDS="xml css" LEVEL="very easy" REFBOOKSS="Dragonbook C-bible" TYPE="theory" xml:lang="en" PREREQUISITES="EBNF HTML3.2">... Jos tiedetään, että XML-dokumentteja kirjoittavat ja lukevat ainoastaan tietokoneohjelmat, suunnittelun painopiste siirtyy "käyttömukavuudesta" laajennettavuuteen ja tehokkuuteen Jos tiedetään, että käyttäjät tuottavat dokumentteja etupäässä editorilla ABC (tai sellainen aiotaan kirjoittaa/ottaa käyttöön N vuoden päästä), kannattaa tämä ottaa reilusti huomioon mietittäessä, miten ja millä tarkkuudella merkkausta kannattaa kirjoittaa 73275 RAKENTEISET DOKUMENTIT (kevät 2003) luentorunko ON 275
Dokumenttiluokan määrittely skeeman määrittäminen Kun tiedetään, minkälaisesta dokumenttiluokasta ja minkä tasoisesta merkkauskäytännöstä (määrittelyvaiheen tarkkuudella) ollaan kiinnostuneita, voidaan suunnitella ja kirjoittaa täsmällinen kuvaus dokumenttiluokan dokumenttien koodauksesta ja loogisesta rakenteesta Viime kädessä kyse on dokumenttiluokan kuvaavan skeeman ([schema]) määrittelystä (vrt. tietokantojen määrittely). Skeemalla tarkoitetaan tässä yhteydessä lähinnä: - täsmällistä mallia ([model]), joka kuvaa dokumenttien koodauksen ja rakenteen JA - mallille asetettavia rajoituksia ([constraints]), jotka rajaavat mallin elementtirakennetta ([content constraint]) ja elementtien sisältöä ([datatype constraint]) Skeeman kuvaamiseen on useita vaihtoehtoja: 1) ohjeistus sanallisesti tai esimerkkien kautta (skeeman määrittely viitaten "tunnettuihin tietotyyppeihin", "malliesimerkkeihin", jne.) 73275 RAKENTEISET DOKUMENTIT (kevät 2003) luentorunko ON 276
2) dokumenttiluokan kuvaaminen XML DTD:n muodossa (skeeman määrittely XML-merkkausdeklaraatioina) 3) dokumenttiluokan kuvaaminen XML Scheman avulla (skeeman määrittely XML Schema -spesifikaation mukaisina kuvausrakenteina) 4) 5) dokumenttiluokan kuvaaminen täsmällisesti suoraan "matalan tason" työvälineillä (esim. suoraan EBNF-notaatiota käyttäen) Tällä kurssilla keskitytään lähinnä tapojen 1 ja 2 yhteiskäytäntöön (="tavallinen tapaus"). Tapaus 3 käsitellään pintapuolisesti XML-stdperheen yhteydessä Skeemaa suunniteltaessa kannattaa käyttää tervettä kaupunkilaisjärkeä: - täsmällisyyteen ei tarkoita samaa kuin "formaalisen näköiseen" pyrkiminen - formaalisella skeeman määrittelyllä ei ole "itseisarvoa" jos esimerkit ajavat saman asian paremmin (paitsi jos tavoitteena malli ohjelmatoteutukselle) - määrittely kannattaa aluksi tehdä niin yksinkertaisesti kuin mahdollista ja miettiä monipuolisempia rakenteita vasta kun nähdään, kelpaako skeema mihinkään 73275 RAKENTEISET DOKUMENTIT (kevät 2003) luentorunko ON 277
Dokumenttiluokkien skeemat Dokumenttiluokkien määrittelyn tapauksessa tyypillisen skeeman malli sisältää seuraavankaltaisia osia: - geneerisen mallin yleiselle elementtihierarkialle - tietue-elementtien esittelyn ja kuvaukset (tietue-elementit samaistetaan tässä kirjallisuudessa mainittavien "informaatioyksiköiden" ja XML Scheman "tyypiltään kompleksisten elementtien" kanssa) - dataelementtien esittelyn ja kuvaukset Tyypillisiä rajoitteita puolestaan ovat: - geneerisen mallin rakennetta säätelevät rajoitteet - dataelementtien sisältämän tiedon tyypin semanttiset rajoitteet - dataelementtien sisältämän tiedon syntaktista rakennetta koskevat rajoitteet 73275 RAKENTEISET DOKUMENTIT (kevät 2003) luentorunko ON 278
Esimerkki kirjeiden luokan määrittävästä skeemasta TO LETTER CONTENT? FROM malli korkean tason elementtihierarkiasta {1,7} PERSON CHAPTER PERSON PERSON tietue-elementtien mallit NAME EMAIL NAME TYPE: string PATTERN: \u\w\w+\s\u\w\w+ EMAIL TYPE: string PATTERN: \w+@[\w\.]+ CHAPTER TYPE: string PATTERN:. dataelementtien kuvaus Huomaa eri tasot ja XML:n DTD-määrittelyn ulottumattomissa olevat piirteet! 73275 RAKENTEISET DOKUMENTIT (kevät 2003) luentorunko ON 279