Henri Sivonen, korkeakouluharjoittelija, Kansallisarkisto
Henri Sivonen on laatinut tämän dokumentin Kansallisarkistossa kesällä 2002. Dokumentti sisältää Sivosen Kansallisarkistolle esittämän näkemyksen. Dokumentti ei välttämättä edusta Kansallisarkiston kantaa (eikä välttämättä edes Sivosen nykyistä kantaa).
SGML on ISO-standardi rakenteisten merkkauskielten määrittelyyn. Rakenteisten merkkauskielten avulla voidaan ilmaista, tekstin eri osien rooli dokumentin rakenteessa (otsikko, kappale jne.). XML on yksinkertaistettu versio SGML:stä. XML:stä on jätetty pois SGML:n vähän käytettyjä ominaisuuksia ja toteutusta monimutkaistavia ominaisuuksia. Lisäksi XML selkiyttää merkistöasioita määrittelemällä, että XML-dokumentin merkit ovat aina olemukseltaan Unicode-merkkejä riippumatta siitä, miten nämä merkit on koodattu taltiolle. XML on W3C:n Suositus.
SGML:n käyttöä arkistoinnin pohjana puoltaisi sen standardiasema ja vakiintuneisuus. XML:n käyttöä taas puoltaa se, että XML on laajalti hyväksytty yksinkertaistettu versio ja yksinkertaisuus on eduksi, kun joudutaan ylläpitämään valmiutta dokumenttien lukemiseen.
Oletan tässä, että XML on riittävä pohja arkistoformaateille eikä SGML:ää kaikkine yksityiskohtineen ole tarpeen tukea. Havaittava trendi on se, että SGML-pohjaisia merkkauskieliä muokataan siten, että niitä voidaan käyttää XML-pohjaisina.
Erityisen huomionarvoista on se, ettei XML sinänsä ole valmis kieli dokumenttien rakenteen koodaamiseen, vaan kehikko konkreettisten kielten määrittelyyn. Konkreettista kieltä kutsutaan XML-sanstoksi (vocabulary). Niinpä jokaista XML-sanastoa pitää tukea ohjelmissa erikseen ainakin jossain määrin. Monesti mainonnassa puhutaan vain XML-tuesta eikä kerrota, millaista XML-sanastoa tuetaan.
Pitkäaikaissäilytyksen kannalta olisi edullista käyttää dokumentin loogisen rakenteen koodaavia XML-pohjaisia dokumenttiformaatteja eikä dokumentin esitykseen painottuvia yksittäisten tekstinkäsittelyohjelmien omia formaatteja.
Kun tiedostoon on koodattu dokumentin rakenne, ei jouduta säilyttämään paperiesityksen yksityiskohtia, vaan voidaan keskittyä olennaisen sisällön säilyttämiseen. Tässä siis lähtökohtaisesti oletetaan, että sisällön olennainen asia on teksti ja siihen liittyvät eri tekstinosien rakenteelliset roolit (otsikot, kappaleet jne.) eikä tekstin tietty asettelu paperille. XML-pohjaisuus puolestaan helpottaa dokumenttiformaattien jatkokäsittelyä ohjelmakohtaisiin binääriformaatteihin verrattuna, sillä XML:n käsittelyyn on saatavilla yleiskäyttöisiä valmiita työkaluja ja tarvittaessa XML-jäsenninkin voidaan kirjoittaa itse XML-määritystä seuraamalla.
Tyypillisesti on helpompaa kirjoittaa ohjelma, joka näyttää jossain tietyssä XML-pohjaisessa muodossa ilmaistuja dokumentteja edes jotenkin mielekkäästi, kuin kirjoittaa ohjelma, joka esittää esim. Word-dokumentteja. Lisäksi rakenteisista dokumenteista voidaan tehdä tekstihakuja toisin kuin esim. bittikartoista ja PDF-tiedostoista. (Ääkkösellinen tekstihaku tai tavutettujen sanojen haku toimii PDF:ien kohdalla vain hyvissä olosuhteissa.) Bittikartat ja PDF:t tarvitsevat tuekseen tekstitiedoston hakuja varten. Tällaisiin tekstitiedostoihin verrattuna rakenteiset formaatit pystyvät tarjoamaan etuna edellytykset löytyneen sanan painoarvon ohjelmalliseen arviointiin. Jos hakuohjelma löytää haetun sanan dokumentin väliotsikosta, dokumentti voidaan esittää käyttäjälle todennäköisesti haun kannalta olennaisempana kuin dokumentti, jossa sama sana löytyy vain tavallisesta tekstikappaleesta.
Monet tekstin merkkaamiseen tarkoitetut SGML- ja XML-sanastot ovat jonkin tietyn organisaation sisäisiä kieliä. Lisäksi monet XML-sanastot eivät varsinaisesti olekaan tekstin merkkaamiseen tarkoitettuja kieliä, vaan pikemminkin muunlaisten datarakenteiden sarjallistusformaatteja. Yli organisaatiorajojen käytettyjä tekstin merkkaamiseen tarkoitettuja sanstoja onkin yllättävän vähän.
HTML, eli WWW-sivujen tavallinen muoto, on ainakin väitetysti SGML-pohjainen kieli. Joidenkuiden mielestä se ei ole oikea SGML-pohjainen kieli mm. siksi, että HTML-määritys pyrkii rajoittamaan SGML:n ominaisuuksien käyttöä dokumentin laadinnassa. Ainakaan yleisesti käytössä olevat selaimet eivät lue HTML-tiedostoja oikealla SGML-jäsentimellä.
XHTML 1.0 on HTML:n uudelleenmuotoilu XML-sanastoksi.
HTML:ää käytetään paljon siksi, että se on Webin natiiviformaatti ja nykyään kutakuinkin kaikilla tietokoneilla on asennettuna jokin WWW-selain. (X)HTML:n elementtivalikoima soveltuu ehkä parhaiten tietokoneaiheisen artikkelin merkkaamiseen. Esim. näppäimistösyötteelle, tietokonekoodille ja esimerkkitulosteella on kaikille omat elementtinsä. Sen sijaan esim. todellisten WWW-sivujen ominaisuuksille kuten navigaation, mainosten ja sisällön erittelylle ei ole (X)HTML:ssä valmiita elementtejä.
XHTML 1.x:stä on olemassa yksinkertaistettu versio XHTML Basic, jonka tukeminen on huomattavasti helpompaa kuin täyden XHTML:n tukeminen.
(X)HTML:ssä voidaan määritellä lomakkeita, jotka liittyvät jonkinlaiseen ohjelmoituun toiminnallisuuteen eivätkä sisältötekstin merkkaamiseen.
DocBook on ohjelmisto- ja laitteisto-ohjekirjojen merkkaamiseen kehitetty SGML-pohjainen kieli ja nyttemmin myös XML-sanasto. DocBookin tueksi on saatavilla suhteellisen paljon työkaluja. Tämä johtuu siitä, että DocBook on suosittu ohjelmointitaitoisten henkilöiden keskuudessa. DocBookia käytetään O'Reillyn kirjojen, monien isojen laitevalmistajien dokumentaation ja monien merkittävien ohjelmistoprojektien dokumentaation tuotannossa.
Text Encoding Initiative on kehittänyt SGML-pohjaisen kielen kertomakirjallisuuden, runouden, puheiden ja lingvististen tekstien koodaamiseen. Nykyään TEI on muotoiltu XML-sanastoksi. TEI soveltuu erityisesti myös olemassa olevien historiallisten tekstien koodaamiseen jälkikäteen, kun taas DocBook on tarkoitettu etupäässä siihen, että uusi teos kirjoitetaan alunperinkin DocBook-muotoon.
Mikään yllä mainituista XML-sanastoista ei sovellu sellaisenaan yksinkertaisten toimistomuistioiden ja pöytäkirjojen merkkaamiseen. Vaikuttaa siltä, ettei tarkoitukseen ole valmiita yleisiä de jure- tai de facto -standardeja. Siispä tarvittava XML:n sovellus tai sovellukset pitäisi kehittää itse. Oman dokumenttityypin luonnissa kannattaa ottaa pohjaksi jokin hyväksi tunnettu dokumenttityyppi kuten DocBook.
Itse kehittämisestä seuraisi se, että myös tarvittava editori tekstinkäsittelyohjelman korvikkeeksi pitäisi kehittää itse. Käytännössä olisi järkevää muunnella jotain open-source -tekstinkäsittelyohjelmaa kuten AbiWordiä.
Alkuvaivan jälkeen saavutettaisiin rakenteisten dokumenttien hyödyt. Jos ohjelman käyttöliittymässä olisi vaikka painike väliotsikolle, olisi rakenteista muotoa tukevan ohjelman käyttö jopa helpompaa kuin sellaisen ohjelman, jossa otsikon tekeminen edellyttää sitä, että käyttäjä vaihtaa ensin fontin Arialiksi, sitten kooksi 18 pistettä ja sitten vielä tyyliksi lihavoidun.
Rakenteisten dokumenttien käyttöönotto ei kuitenkaan ole helppoa. Hiemankin monimutkaisempien dokumenttityyppien määrittely hyvin edellyttää tarkkaa tarpeiden kartoittamista ja paljon suunnittelutyötä. Suunnittelutyötä voidaan kyllä helpottaa käyttämällä DocBookia tai muuta hyväksi todettua dokumenttityyppiä mallina. Erityisesti dokumenttityyppien määrittelyssä tarvitaan henkilöitä, jotka tuntevat hyvin kohdeympäristön tarpeet ja osaavat kertoa, millaisia rakenteita pitää pystyä ilmaisemaan. Lisäksi toimintatapojen muutos ja erilaisten ohjelmien käyttöönotto on aina vaikeaa saada läpi isoissa organisaatioissa.
Rakenteisiin dokumentteihin siirtymistä eduskunnassa on käsitelty [1]:ssä.
Jos tavallista tekstinkäsittelyohjelmaa on käytetty täysin esityksellisesti eli rakenteet on ilmaistu vain ihmislukijoille fontin, fonttikoon ja tyylitysten valinnalla, dokumenttia ei voi muuttaa kunnollisesti rakenteiseksi ohjelmallisesti (ainakaan ilman monimutkaista tekoälyä).
Monissa tekstinkäsittelyohjelmissa on kuitenkin tyylijärjestelmä, jossa voidaan antaa tyylikombinaatioille nimiä. Menettely yrittää mukailla rakenteellista merkkausta mutta poikkeaa siitä sikäli, ettei tyyli yleensä voi riippua rakenteiden kontekstista, vaan konteksti voi korkeintaan vaikuttaa siihen, mikä tyylinimi seuraa toista dokumenttia kirjoitettaessa. Monesti tekstinkäsittelyohjelmissa ei voi määritellä, että väliotsikkoa suoraan seuraava kappale on tyyliltään erilainen kuin muut kappaleet, mutta voidaan määritellä, että väliotsikossa returnin painaminen aloittaa lohkon, jonka tyylin nimi on ”otsikonjälkeinen kappale” ja tässä lohkossa returnin painaminen aloittaa tavallisen kappaleen. Siispä se, että tarvitaan erilainen tyyli edellyttää uuden pseudorakenteellisen osan nimeämistä, vaikka oikeassa rakenteellisessa merkkauksessa ei oteta kantaa siihen, tyylitetäänkö väliotsikkoa seuraava kappale eri tavalla.
Hyvissä olosuhteissa ja oikein käytettyinä tekstinkäsittelyohjelmien nimetyt tyylit tarjoavat sen verran informaatiota rakenteesta, että tekstinkäsittelydokumentti voidaan muuttaa johonkin yksinkertaiseen oikeaan rakenteelliseen formaattiin. Kuitenkin tekstinkäsittelyohjelmien oletusarvoiset käyttöliittymäkonfiguraatiot eivät muodosta tarvittavia hyviä olosuhteita. Oletusarvoisesti mikään ei estä käyttäjää tekemästä asioita, jotka rikkovat konversiomahdollisuudet. Tästä syystä tavallisen tekstinkäsittelyohejlman käyttö rakenteisten dokumenttien luomiseen edellyttää käytännössä sitä, että käyttöliittymää rajataan (esim. työkalupalkkeja ja valikoita muokkaamalla).
Tämä saattaa ensisilmäyksellä vaikuttaa huonompaan suuntaan siirtymiseltä, mutta jollei suoraan merkkeihin liittyvien fonttityylien käyttöä rajoiteta, ei saada rakenteisuuden hyötyjä ja ollaan sidoksissa yhteen esitykseen. Jukka Korpela on kiteyttänyt asian seuraavasti:
”Kuvailevan merkkauksen voima on siinä, että se ei salli määrätä ulkoasua vaan erottaa muuttumattoman rakenteen muuttuvaisista esitysmuodoista. Asian luonteeseen kuuluu, että ne, jotka eivät tätä ole tätä vielä sisäistäneet, pitävät sitä suurena heikkoutena ja pahana puutteena.”[2]
WYSIWYG-ajatteluun sitoutuneiden tekstinkäsittelyohjelmien käyttäminen presentationaalisia ominaisuuksia rajoittamatta tarkoittaa sitä, että asiat tehdään paperiajattelun mukaan ja sitten arkiston ja e-Government -pyrkimysten toteuttajien on sopeuduttava käsittelemään paperin kuvien digitaaliesityksiä. Kuitenkin jos todella halutaan irroittautua paperista ja koodata sisältöä eikä sisällön kuvaa, olisi järkevää luopua ulkonäköön perustuvasta dokumenttien luonnista. Rakenteellisen merkkauksen käyttö helpottaisi sekä dokumenttien esittämistä erilaisilla näyttölaitteilla että dokumenttien arkistointia huomattavasti.
[1] Experiences of SGML Standardization: The Case of the Finnish Legislative Documents. Airi Salminen, Virpi Lyytikäinen, Pasi Tiitinen ja Olli Mustajärvi. Proceedings of the 34th Hawaii International Conference on System Sciences. 2001 URL: http://dlib.computer.org/conferen/hicss/0981/pdf/09815003.pdf
[2] Merkkauskielten idea. Jukka Korpela. 2000. URL: http://www.cs.tut.fi/~jkorpela/html/merkkaus.html
Text Encoding Initiativen WWW-sivusto. URL: http://www.tei-c.org.uk/
DocBook Technical Committeen sivut. URL: http://www.oasis-open.org/docbook/
DocBook Open Repository -projekti SourceForgessa. URL: http://sourceforge.net/projects/docbook
W3C:n HTML-sivut. URL: http://www.w3.org/MarkUp/