Mikä on XML?

Mitä XML on? Eräs viime vuosien käytetyimmistä akronyymeistä tunkee joka paikkaan, mutta sen merkityksestä on paljon epätietoisuutta. Tämä juttu pyrkii valottamaan XML:n olemusta erityisesti sellaisen ihmisen näkökulmasta, jolla on jo jonkin verran kokemusta HTML-julkaisemisesta. Lähestymistapa on tietoisen epätieteellinen.

XML (Extensible Markup Language) on metakieli, jolla määritellään rakenteellisia merkkauskieliä. Tässä on tärkeä ero XML:n ja HTML:n välillä: HTML on merkkauskieli, XML:llä luodaan sellaisia. Ei siis edes ole varsinaisesti edes olemassa "XML-dokumenttia"; jokainen "XML-dokumentti" on aina kirjoitettu jollain XML:n avulla määritellyllä kielellä.

Mikä sitten on SGML? Se on XML:n edeltäjä, jo 1980-luvulla syntynyt merkkauskielten määrittelyyn tehty metakieli. Mm. HTML on yksi SGML-pohjainen kieli ("SGML application"). XML:ää voidaan hyvällä syyllä pitää SGML:n yksinkertaistettuna versio.

Ei mikään HTML 2

XML ymmärretään paremman tiedon puutteessa usein HTML:n korvaajana. Sitä se ei missään nimessä ole, vaikka tekniikoille onkin joitain yhteisiä käyttökohteita. XML-kieliä voi käyttää minkä tahansa tiedon kuvailemiseen, kun taas HTML on tarkoitettu nimenomaan verkkojulkaisun rakenteen ilmaisemiseen. Käytetään esimerkkinä vaikkapa pientä puhelinluetteloa. Sitä voisi kuvata esimerkiksi seuraavalla XML-pätkällä:

<puhelinluettelo>
   <henkilo>
       <nimi>Jouni Heikniemi</nimi>
       <osoite>Kotikuja 2 C 57</osoite>
       <puhnro tyyppi="koti">07-2345678</puhnro>
   </henkilo>
   <henkilo>
       <nimi>Simo Simpukka</nimi>
       <osoite>Jugendstrasse 8 Z 22</osoite>
       <puhnro tyyppi="gsm">048-3322211</puhnro>
       <puhnro tyyppi="koti">07-8765432</puhnro>
   </henkilo>
</puhelinluettelo>

Esimerkissä on jotain samaa kuin tavallisessa HTML-dokumentissa. Näkyvin yhteinen piirre on kulmasuluilla erotettujen tagien käyttö rakenteen antajina. Esimerkiksi <henkilo>-aloitustagin ja </henkilo>-lopetustagin väliin sijoittuvat yhden henkilön luettelotiedot - nämä kaikki yhdessä muodostavat siis yhden henkilo-elementin. Tutuista piirteistä huolimatta erojakin löytyy - eiväthän nämä käytetyt tagit ole ollenkaan samoja kuin HTML:ssä! Aivan - olemme tässä ohimennen määritelleet oman puhelinluettelokielen, jota voidaan nyt kutsua vaikkapa PMK:ksi (Puhelinluettelon MerkkausKieli).

Rakenteen muodollinen määrittely: DTD

Oikeastaan edellä esittämämme määrittely on vielä aika summittainen. Se kertoo PMK:sta ainakin sen, että puhelinluettelo-tagien sisällä voi olla henkilöitä, joiden sisällä voi olla nimiä, osoitteita, puhelinnumeroita ja niin edelleen. Toisaalta se ei kerro, voiko PMK-dokumentissa olla jotain muutakin: voisiko jotenkin esimerkiksi merkitä, että Simo onkin Jounin setä, tai voisivatko nimet ja osoitteet olla erilaisessa järjestyksessä?

Muodollisen kieliopin kuvaamiseen tarvitaan kielen DTD (Document Type Definition, dokumenttityypin määrittely). DTD on tekstitiedosto, joka kirjoitetaan erityisessä muodossa (joka ei ole XML:ää). Pienen puhelinluettelokielemme DTD-määrittely voisi olla esimerkiksi seuraavan näköinen:

<!ELEMENT puhelinluettelo (henkilo)+>
<!ELEMENT henkilo (nimi, osoite, puhnro*, kuvaus?)>

<!ELEMENT nimi (#PCDATA)>
<!ELEMENT osoite (#PCDATA)>
<!ELEMENT puhnro (#PCDATA)>
<!ELEMENT kuvaus (#PCDATA)>

<!ATTLIST puhnro
     tyyppi     CDATA    #REQUIRED>

Mitä DTD sitten meille kertoo? Se määrittelee elementit, niihin kuuluvat attribuutit (eli määreet) ja elementtien väliset suhteet. Vertaa seuraavaa sanallista selitystä lukiessasi DTD:tä ylläolevaan esimerkkidokumenttiin. Varmista, että ymmärrät kaiken.

DTD:n ensimmäinen rivi kertoo, että PMK-dokumentissa esiintyy puhelinluettelo-elementtejä. Rivin loppuosa (henkilo)+ ilmaisee, että puhelinluettelon sisältönä voi olla yksi tai useampia henkilo-elementtejä. Plus-merkki tarkoittaa siis ilmaisua "yksi tai useampi kappale".

Toinen rivi ilmaisee, että henkilo-nimisen elementin sisältönä on ensin nimi-, sitten osoite-, puhnro- ja kuvaus-elementit. Puhnro-elementin nimen perässä oleva tähti tarkoittaa, että puhelinnumeroita voi olla nolla tai useampia. Kuvaus-sanan perässä oleva kysymysmerkki puolestaan kertoo, että kuvaus-elementtejä esiintyy nolla tai yksi kappaletta: siis kuvaus voi joko olla olemassa tai sitten ei. Esimerkissämme kuvausta ei käytetty ollenkaan.

Seuraavat neljä riviä määrittelevät, että nimi-, osoite-, puhnro- ja kuvaus-elementit voivat sisältää vain tekstiä (#PCDATA, engl. Parsed Character Data), eivätkä siis lainkaan toisia elementtejä. Loppuosa DTD:stä sisältää ATTLIST-määrittelyn, joka kertoo, että puhnro-nimisellä elementillä voi olla tyyppi-niminen attribuutti (eli määre), jonka sisältö on tyyppiä CDATA (merkkijono, engl. character data).

Jos kaikki ylläoleva on sinulle selvää, tiedät jo aika paljon XML-dokumentin olemuksesta. Ymmärrät nyt, miten PMK-kielinen dokumentti rakentuu ja miten sen DTD rakentuu. DTD:n avulla voidaan luoda monia muitakin rakenteita, mutta niitä ei käsitellä sen tarkemmin tässä.

Dokumentin muodollisen määrittelyn ymmärtäminen on olennaista, vaikka tosimaailmassa hyvin monet XML-dokumentit liikkuvat tyystin ilman DTD:tä. Tässä on kysymys eräästä XML:n piirteestä: dokumentti on oikein muodostettu (well-formed), jos se rakentuu XML:n yleisen syntaksin mukaisesti. Tällöin se on jo sinänsä ihan kelvollista XML:ää. Pelkkä oikeamuotoisuus ei kuitenkaan riitä rajattomasti, sillä tiedon järkevyyden tarkistamiseen tarvitaan myös kielioppia: eihän olisi ollenkaan järkevää, että esimerkiksi osoite-elementin sisällä olisi uusi puhelinluettelo-elementti! Kun dokumentti on sekä XML-syntaksin että DTD:nsä mukainen, sen sanotaan olevan validi (engl. valid).

DTD-määrittelyssäkin on puutteensa. Yksinkertaisella symboliikalla ei esimerkiksi voida ilmaista sitä, että jotain elementtiä saisi olla vaikkapa 2-5 kappaletta, tai että puhelinnumerossa ei saa olla kirjaimia. Tätä tarkoitusta varten on olemassa DTD:n korvaava XML Schema -määrittely, jota ei kuitenkaan käsitellä tässä yhteydessä.

XML-syntaksi

Aiemmin on viitattu useampaan otteeseen XML:n syntaksiin. Siinä kyse on varsin yksinkertaisesta joukosta pieniä sääntöjä, jotka määrittelevät XML-dokumentilta vaadittavan muodon. Kuten aiemmin todettiin, nämä muotosäännöt täyttävä dokumentti on siis ns. oikein muodostettu (well-formed), jota voi jo käyttää melkein missä tahansa XML-ympäristössä. Toinen asia on sitten se, että tiedon sisällöllinen järkevyys voidaan tarkistaa vain DTD:n tai Scheman avulla (jos niilläkään - joskushan tarkastelu vaatii ihmisaivoja tai ainakin monimutkaista toteutusspesifistä koodia).

XML:ää kirjoittaessa on aika työntää syrjään ns. tagsoup-ajattelu. Jos olet kirjoittanut HTML:ää periaatteella "tässä on vähän tekstiä ja sitten laitan sinne tänne tageja luomaan rakennetta", tulet törmäämään XML:n kanssa ongelmiin. Tässä vaiheessa oikea ratkaisu on ryhtyä käsittelemään dokumenttia sisäkkäisten elementtien kokonaisuutena. Kun tuotat sisältöä, mieti sen muodostamia loogisia kokonaisuuksia. Nämä jäsentyvät elementeiksi: puhelinluettelossa siis esimerkiksi henkilöiksi, joihin kuuluu edelleen nimi, osoite, puhelinnumeroita ja mahdollinen kuvaus.

Muutakin kuin dokumentin rakennetta

Tässä vaiheessa on hyvä karistaa pois myös käsitykset siitä, että XML olisi tarkoitettu julkaistavan materiaalin rakenteen kuvaamiseen. Siinä oli jo kaksi virhettä: XML:llä ei välttämättä ole mitään tekemistä julkaisutoiminnan kanssa, ja toisaalta XML ei mitenkään välttämättä kuvaile dokumentin rakennetta. On siis tärkeää ymmärtää, että vaikka XML-kielet itsessään ovat rakenteellisia (eli ne koostuvat sisäkkäisistä elementeistä), ne voivat kuvata myös muuta kuin rakennetta. XML-kielillä voidaan kuvata mitä tahansa millä tahansa äärellisellä tarkkuuden tasolla, mitä seuraavat pari esimerkkiä pyrkivät osoittamaan.

Esimerkki 1: Kuvitteellinen robotinohjauskieli

Otetaan esimerkiksi kuvitteellinen XML-pohjainen kieli, jolla ohjataan kotitöitä tekeviä robotteja. Sillä tehty pätkä voisi näyttää vaikkapa seuraavalta:

<komentosarja nimi="pyykinnouto">
    <vaihe numero="1">
        <liiku suunta="eteenpain" maara="20m"/>
        <kaanny suunta="vasemmalle" maara="90ast"/>
    </vaihe>
    <vaihe numero="2">
        <sano aani="normaali">Anna minulle pestävät pyykit.</sano>
        <odota mitatapahtumaa="saapyykkia" odotusaika="20sek"/>
    </vaihe>
</komentosarja>

Tämä dokumentti ei liity mitenkään julkaisutoimintaan, vaan se on ohjausdataa jollekin ohjauskieltä ymmärtävälle robotille. Esimerkissä robotti ohjelmoidaan liikkumaan oikeaan paikkaan, pyytämään pyykkiä ja odottamaan sitä 20 sekuntia. Tämä pieni XML-pohjainen kieli ei määrittele kaikkea toimintaan liittyvää: esimerkiksi sano-elementin attribuutti aani sai arvokseen "normaali". Tämä olisi varmaakin normaalitilanteessa hyvä ratkaisu, mutta määrittelyä voisi tarkentaakin, jos robotin puhetyyliä eri tilanteissa halutaan ohjata tarkemmin. Sano-elementin voisi (jos DTD sen sallii) kirjoittaa vaikkapa näin:

   <sano>
      <teksti>Anna minulle pestävät <painota>pyykit</painota>.</teksti>
      <aani>
          <taajuus yksikko="Hz">250</taajuus>
          <voimakkuus yksikko="dB">50</voimakkuus>
      </aani>
      <aani tapa="painotetettu">
          <taajuus yksikko="Hz">270</taajuus>
          <voimakkuus yksikko="dB">55</voimakkuus>
      </aani>
   </sano>

Tällöin robotti lausahtaisi tekstin 250 hertsin taajuudella ja 50 desibelin voimakkuudella, mutta painota-elementin sisältö lausuttaisiin 20 hertsiä korkeammalla ja 5 desibeliä voimakkaammalla äänellä.

Kukaan tuskin haluaa ohjata robottinsa toimintaa näin tarkalla tasolla ainakaan arkielämässä. Esimerkin tarkoitus oli kuitenkin osoittaa, että XML-kielet ovat sitä mitä niiden tekijät haluavat: jos tarve on luoda yksityiskohtaista merkintää esimerkiksi puhesynteesille, se onnistuu. Jos tarkoitus on luoda vain hyvin yleisluonteista kuvausta toiminnoista, koko sano-elementin voisi ehkä korvata vain yleisluontoisella <pyydapyykkia/>-elementillä, jolloin itse robotin toteuttaja voi hyvinkin laajalti valita, miten pyykkiä pyydetään.

Esimerkki 2: XSL-FO

Myös julkaisutoiminnassa voidaan käyttää erittäin eksaktia ilmaisua tietyissä oloissa silloin, kun lopputulos on asetellaan täsmällisesti määritellylle pinnalle kuten A4-arkille. Eräs tekniikka, jota tässä yhteydessä ei tarkemmin käsitellä, on XSL-FO-niminen muotoilukieli, joka mahdollistaa millimetrintarkan materiaalin sijoittelun esim. paperitulostusta varten. FO:kin (Formatting Objects) on XML-pohjainen kieli, joka näyttää esimerkiksi tällaiselta:

   <block space-after.optimum="2mm" border="1mm black solid" font="9.5pt/1.1 monospace">
       Tämä tulostuu 9,5 pisteen monospace-fontilla ja
       <inline font-weight="bold">tämä on lihavoitua</inline>
   </block>

Kukaan ei siis sano, että XML- kielen tarvitsisi kuvata dokumenttia vain rakenteen tasolla: esimerkiksi FO:ssa kaiken voi (ja itse asiassa myös pitää) määritellä hyvin yksityiskohtaisesti. Vielä FO:takin pidemmälle menevä esimerkki on SVG (Scalable Vector Graphics), joka on kuvien tallennusmuoto - mutta hieman yllättäen XML-pohjainen sellainen. SVG:stä voit lukea lisää W3C:n SVG-sivuilta.

XML-perhe

Pelkkä XML ei sinänsä ole muuta kuin tietomuoto. Suuri osa sen hyödyllisyydestä johtuukin siitä, että XML-tekniikan ympärille on rakentunut huomattava määrä valmiita sovelluksia ja rinnakkaistekniikoita, jotka täydentävät rakenteellista merkkausta ja sen käyttömahdollisuuksia. Tässä jaksossa perehdytään lyhyesti keskeisimpiin XML-maailman otuksiin.

Parseri eli jäsennin

XML:ää, kuten kaikkia muitakin tallennusmuotoja, täytyy jollain tavalla tulkita ennen tietojen käyttöä. Rakenteellisen merkkauksen kohdalla se tarkoittaa sitä, että yksiulotteisesta tekstimassasta poimitaan esiin elementit ja muodostetaan niistä puumalli, jossa elementit ovat sijoitettuna sisäkkäin. Tämä tulkitseminen on parserin eli jäsentimen tehtävä. Yksinkertaisimmillaan jäsennin "vain" lukee rakenteen ja muodostaa siitä puun, mutta käytännössä lähes kaikki jäsentimet myös tekevät ainakin jonkinlaisen muototarkistuksen.

Useimmille jäsentimille riittää se, että dokumentti on oikeamuotoinen (well-formed), kun taas jotkut hallitsevat myös DTD:n ja/tai Scheman mukaan validoinnin. Tarpeesta riippuu, kuinka perusteellista oikeellisuuden tarkastelua kannattaa tehdä. XML-kielten tulkitsemiseen liittyy se HTML:n tekijöille vieras piirre, että yleensä ohjelmat hylkäävät XML-dokumentin, jos siinä on yksikin virhe, kun taas HTML:ää yritetään usein (erityisesti selaimissa) tulkita väkisin virheistä huolimatta. Tämän vuoksi XML-kielten jäsentämisessä syntyy vähemmän tulkintavirheitä, mikä edelleen johtaa yhtenäisempiin ja selkeämpiin toteutuksiin.

Eräs XML:n vahvuus on se, että sopivia parsereita on saatavilla pilvin pimein. Lähes kaikille ohjelmointikielille on saatavilla valmiit kirjastot, jotka jäsentävät XML-kielistä lähdetietoa. Niinpä XML-muotoa voi yleensä käyttää omissa ohjelmissa hyvin helposti, koska tallennusmuodon käsittelyrutiineja ei tarvitse kirjoittaa itse.

Xpath

Eräs XML-toteutuksiin liittyvä tekniikka on Xpath. Se on yksinkertainen kyselykieli, jolla voidaan hakea erilaisia tietoja XML-dokumentin sisältä. Xpathia ei opeteta tässä, mutta pari esimerkkiä valaisee, millaisiin tehtäviin sitä voidaan käyttää. Käytetään esimerkkinä seuraavaa XML-dokumenttia:

<esineet>
  <kori>
      <hedelma tyyppi="omena">Tämä on omena</hedelma>
      <hedelma tyyppi="banaani">Tämä on banaani</hedelma>
      <hedelma tyyppi="greippi">Tämä puolestaan on greippi.<elukka/></hedelma>
      <hedelma tyyppi="banaani" koko="iso">Tämä on toinen banaani</hedelma>
  </kori>
  <tavara tyyppi="vasara"/>
</esineet>

Xpath muistuttaa itse asiassa melko paljon käyttöjärjestelmän hakemistopuussa liikkumista. Esimerkiksi Xpath-lauseke /esineet palauttaisi kaikki esineet-elementin sisällä olevat asiat, siis korin ja tavaran tyyppiä vasara. Vastaavasti lausekkeella /esineet/kori palautuisi pelkästään hedelmäkorin sisältö.

Parhaat Xpathin ominaisuudet tulevat esiin monimutkaisempien hakujen yhteydessä. Esimerkiksi lauseke //hedelma[@koko="iso"] palauttaa kaikki dokumentissa olevat isot hedelmät - siis ne, joille on määritelty attribuutin "koko" arvoksi "iso". Tässä tapauksessa tuloksena palautuisi jälkimmäinen banaani-elementti. Esimerkiksi lauseke //hedelma[elukka] palauttaisi ne hedelmät, joiden sisällä on elukka-elementti - eli tässä tapauksessa greipin.

Monet jäsentimet toteuttavat Xpathin sisäisesti, ja helpottavat näin ohjelmoijan työtä entisestään. Jos esimerkiksi yllämainitun kaltaisten tavaraluetteloiden käsittelyohjelmaa tekevä koodari haluaa nopeasti etsiä koreista vain isot hedelmät, hän voi tehdä sen suoraan Xpathilla, tarvitsematta käsin tutkiskella kaikkia elementtejä. Ohjelmoijien lisäksi Xpath on pohjana monessa muussa XML-tekniikassa.

XSLT

XSLT (XSL Transformations, jossa XSL on Extensible Stylesheet Language) on ehkä tärkein XML:n liitännäistekniikka Xpathin ohella. XSLT mahdollistaa XML:n käytettävyyden muiden tietomuotojen raakadatana: siis käytännössä XML-dokumenttien helpon muuntamisen toiseksi XML-kieleksi.

XSLT-tyylitiedostot määrittelevät täsmällisesti, miten yksi dokumentti muunnetaan toiseen muotoon. Käytännössä muunnokseen tarvitaan siis lähdedokumentti, XSLT-tyylitiedosto ja XSLT-käsittelyohjelma. Kuten jäsentimiä, myös XSLT-toteutuksia on saatavilla useille käyttöjärjestelmille ja lähes kaikille ohjelmointikielille. Sellainen on siis helppo upottaa mukaan myös omaan ohjelmaan.

Dokumentille tehtävä muodonmuutos voi käytännössä olla hyvin monimutkainen. Se saattaa hävittää tai lisätä tietoa - tai vain muuttaa olemassa olevan tiedon eri muotoon. Valitettavasti XSLT-muunnosten tekemiseen liittyviin yksityiskohtiin ei tässä yhteydessä ole mahdollista paneutua muuten kuin yhden esimerkin verran.

Palataan hetkeksi vielä aiempaan puhelinluetteloesimerkkiin. Siitä ei vielä sellaisenaan olisi kovin paljon hyötyä, jos haluaisit vaikkapa tehdä puhelinluettelosta verkkosivun. Tässä kuitenkin XSLT tulee avuksi, sillä sen avulla voit muuntaa XML-puhelinluettelosi suoraan HTML-kielelle, jota selaimetkin ymmärtävät. Samalla on myös melko vaivatonta tehdä toinen XSLT-muunnos, jolla voit pyöräyttää samasta puhelinluettelosta FO-version - siis vaikkapa painokelpoisen paperitulosteen.

Tämä on itse asiassa eräs tärkeimmistä XML:n hyötysovelluksista julkaisutoiminnassa: jonkin dokumentin lähdetietoa voidaan ylläpitää yhtenä kappaleena jossain tarkoitukseen sopivassa XML-muodossa, ja XSLT-muunnoksin vain pyöräytetään lähdetiedosta tarvittavat muodot (esim. www-sivut, kirjapainolle tarvittavat paperioriginaalit ja WAP-sivut). XSLT:n avulla voidaan myös generoida tiivistettyä tietoa: esimerkiksi XML-muotoon tallennetusta kirjasta syntyy helposti vaikkapa web-sisällysluettelo, kun valitaan lähdetiedosta pelkästään lukujen otsikot ja tulostetaan ne sopivaksi HTML-rakenteeksi.

Upottaminen ja nimiavaruudet

XML:n olemukseen kuuluu sen laajennettavuus, josta myös lyhenteen X (Extensibility) tulee. Eräs tämän laajennettavuuden ilmenemismalli on se, että erilaisilla XML-kielillä toteutettuja dokumentteja voidaan upottaa sisäkkäin, jos tulkitseva ohjelma vain ymmärtää näitä kieliä. Jos samassa dokumentissa on useita eri kieliä, kielet erotetaan toisistaan nimiavaruuksien (namespaces) perusteella.

Nimiavaruuksien tunnusmerkki on elementin tai attribuutin nimessä esiintyvä kaksoispiste. Esimerkiksi alkutagi <pmk:puhelinluettelo xml:lang="fi"> tarkoittaa, että elementin nimi on "puhelinluettelo" pmk-nimisessä nimiavaruudessa, ja sillä on xml-nimiavaruuden lang-attribuutti, jonka arvo on "fi".

Käytännön esimerkki upottamisesta voisi olla esimerkiksi tilanne, jossa puhelinluettelossamme olevat osoitteet halutaan merkitä yleisellä "osoitteenmerkkauskielellä". Annetaan puhelinluettelokielellemme nimiavaruus pmk ja osoitekielelle nimiavaruus osoite. Näin syntyy esimerkiksi seuraava pätkä:

<pmk:puhelinluettelo>
   <pmk:henkilo>
       <pmk:nimi>Jouni Heikniemi</pmk:nimi>
       <pmk:osoite>
           <osoite:katu>Kotikuja</osoite:katu> 
           <osoite:talonumero>2</osoite:talonumero>
           <osoite:porras>C</osoite:porras> 
           <osoite:asunto>57</osoite:katu> 
       </pmk:osoite>
       <pmk:puhnro tyyppi="koti">07-2345678</pmk:puhnro>
   </pmk:henkilo>
</pmk:puhelinluettelo>

Upottamisen käytännön sovelluksia on useita. Jo aiemmin mainittiin, että SVG-kuvamuoto on itse asiassa XML:ää. Niinpä jatkossa verkkosivujen kuvitusta ei ole pakko sijoittaa aina erilliseen tiedostoon, vaan yksinkertaiset kuvat voi kirjoittaa suoraan normaalin HTML-koodin sekaankin: siis vaikkapa P-elementin sisältä voisi löytyä svg-nimiavaruuteen kuuluvia elementtejä siitä kohtaa, mihin kuva lopullisessa dokumentissa ilmestyy. Vastaavasti web-sivulle tarvittava matemaattinen lauseke voitaisiin toteuttaa pienellä HTML-dokumenttiin upotetulla MathML-kielisellä pätkällä.

XML:n nimiavaruudet ja useiden dokumenttityyppien sekoittaminen ovat käytännössä varsin monimutkaisia asioita, ja toisaalta vielä toistaiseksi myös melko harvoin käytettyjä. Ennen niiden opettelua on syytä hallita vakaasti XML:n ja siihen liittyvien muiden tekniikoiden perusteet.

Tulevaisuuden alusta www-julkaisuun?

XML:ssä on kiistatta monia hyviä piirteitä, joiden vuoksi se tulee vaikuttamaan mm. www-julkaisemiseen tulevaisuudessa. Mutta millä tavalla? XML-kielet tuskin tulevat korvaamaan HTML:n käyttöä. Toisaalta taustavoimina pyörivät jo nyt yhä useammin XML-pohjaiset julkaisuvälineet. Seuraavassa katsaus mahdollisuuksiin ja näkymiin nimenomaan verkkojulkaisun osalta.

XHTML

Tässä jutussa on useaan kertaan mainittu HTML. Oikeastaan tämä maininta on hieman epätarkka, sillä HTML:n kehitys sellaisenaan on lopetettu. Manttelinperijä on XHTML (Extensible Hypertext Markup Language), joka ei oikeastaan eroa HTML:stä juurikaan - vielä.

Tällä hetkellä (helmikuussa 2002) vakiintuneessa asemassa oleva XHTML 1.0 on oikeastaan vain HTML 4.01 muunnettuna SGML-kielestä XML-kieleksi. Mitä vaikutuksia tällä käytännössä on? Oikeastaan ei juurikaan muuta kuin sulkutagit, attribuuttien lainausmerkit sekä isojen ja pienten kirjainten eroavuus - siis käytännössä XML-syntaksin asiat. Miksi XHTML on sitten tärkeä muutos HTML:stä?

Yksi perustavaa laatua oleva syy on modulaarisuus - eli oikeastaan se X, laajennettavuus. Vanhassa HTML:ssä ei tunneta nimiavaruuden käsitettä, joten esimerkiksi MathML:n tai SVG:n upottaminen dokumentteihin on mahdotonta. Toinen tärkeä syy on automaattinen käsiteltävyys: määritelmän mukaan tehty XHTML-dokumentti on, huolimatta siitä että se näyttää melkein HTML:ltä, kelvollista XML:ää. Tämä tarkoittaa mm. sitä, että XSLT-välineillä on mahdollista käsitellä myös XHTML-dokumentteja ja vaikka muodostaa niistä automaattisia sisällysluetteloita tai PDF-versioita.

Webin tekijät tulevat siirtymään XHTML:ään tulevina vuosina, mutta aikaa se vielä vie. Muutos on kuitenkin merkittävä myös siksi, että kuten aiemmin jäsentimistä puhuttaessa todettiin, XML-dokumentissa ei saa olla virheitä. Jos myös webissä päästäisiin siihen, että kaikki HTML-sivut olisivat koodiltaan valideja, sivujen tekeminen yksinkertaistuisi - olisi vain yksi oikea tapa ilmaista joku tietty asia. Huomattavaa merkitystä tällä voisi olla myös selainten kehittämisen kannalta: eräiden arvioiden mukaan tällä hetkellä selaimen HTML-tukeen tarvittavasta lähdekoodista kaksi kolmannesta liittyy epästandardin merkinnän tulkitsemiseen ja vain yksi kolmannes on varsinaista toteutustyötä. Jos tämä työmäärä voitaisiin ohjata tuottavampiin kohteisiin, tulos voisi hyödyttää jopa loppukäyttäjääkin.

Käytännössä tämä on ylioptimistista, ja täydelliseen validiuteen tuskin päästään jatkossakaan. Suunta on kuitenkin oikea ja pyrkimys siihen vakaa. Nykyisellään XHTML:n käyttöön voi jo siirtyä, sillä vaikka se ei olekaan teoreettisesti yhteensopiva HTML:n kanssa, käytännössä selaimet kuitenkin ymmärtävät XHTML:ää varsin hyvin.

XML ja CSS

CSS2 on eräs viime vuosien aliarvostetuimmista uusista tekniikoista. Sen merkitystä ei tajuta, ja aika harva webbimestari on edes ikinä perehtynyt siihen, mitä kaikkea kakkosversion tyylitiedostoilla voisi tehdä. Osittain tämä johtuu myös siitä, että selainvalmistajia vaivaa sama tauti: kunnollisia CSS2-toteutuksia on saanut odottaa vuositolkulla, ja vaikka uudet selaimet kohtuullisesti uutta CSS:ää puhuvatkin, markkinoilla on edelleen koko joukko vanhempia ja huonompia toteutuksia.

Miten CSS sitten liittyy XML:n verkkojulkaisuun? Pääasiassa siten, että eräs sen olennaisimmista uudistuksista oli mahdollisuus tyylitellä HTML:n lisäksi myös XML-dokumentteja. Tämä ominaisuus on itse asiassa hiipinyt selaimiinkin jo jonkinlaisella tasolla, vaikka täydellisestä toteutuksesta ollaankin vielä hyvin kaukana. Leipätekstiä on täysin mahdollista tyylitellä, ja yksinkertainen XML-dokumentti on mahdollista saada näkymään vaikka IE 5.0:ssa (saatikka sitten uudemmassa selaimessa tai kutossarjan Netscapessa, Mozillassa ym.). Kokeile itse: tallenna seuraava xml-dokumentti esim. nimelle koe.xml.

<?xml version="1.0" encoding="iso-8859-1"?>
<?xml-stylesheet href="oma.css" type="text/css"?>

<juttu>
   <ylaotsikko>Tämä on yläotsikko</ylaotsikko>
   <kappale>Tekstiä</kappale>
   <otsikko>Otsikko</otsikko>
   <kappale>Tekstiä lisää</kappale>
</juttu>

Tallenna sitten seuraava tyylisivu nimelle oma.css.

kappale { display: block; }
otsikko { display: block; font-weight: bold; margin-top: 0.5em; }
ylaotsikko { display: block; font-weight: bold; font-size: 200%; margin-top: 0.5em; }

Kokeile nyt ladata sivu selaimella. Tulos ei ole kaunis, mutta se kuitenkin toimii - kunhan et halua toteuttaa mitään kovin monimutkaista kuten linkkejä, kuvia ja taulukoita... Siis: jo nyt on mahdollista julkaista materiaalia XML-muodossa - mutta valitettavasti tie on ongelmien runtelema. Lisäksi raa'an XML:n julkaiseminen tällä hetkellä on ongelmallista, koska vanhoja selaimia käyttää vielä moni, ja niille XML ei avaudu oikein mitenkään.

CSS2 tarjoaa mahdollisuudet mm. vapaamuotoisen XML:n muotoiluun taulukoksi selaimessa - siis teoriassa CSS2:n välityksellä on mahdollista kertoa selaimelle, mikä XML-elementti kuvaa taulukon riviä (HTML:n tr), mikä solua (td) ja niin edelleen. Käytännössä selainten kyky ymmärtää tätä viestiä on ainakin tällä hetkellä varsin rajoittunut, ja niinpä oikean muotoilun ilmestyminen ruudulle on lähinnä sattumaa.

Ja vaikka XML-CSS-yhdistelmä toimisikin täysin, eräs varsin vakava ongelma jää jäljelle: XML-elementeillä ei ole julkista, valmiiksi määriteltyä semantiikkaa. Siinä missä kaikki voivat lukea, että XHTML:n h3 tarkoittaa kolmannen tason otsikkoa ja acronym kirjainlyhennettä, miten selain tietäisi, mitä joku OmaML:n <tokantasonotsikko> tarkoittaa?


CSS on tarkoitettu ehdottamaan suositeltavaa tapaa esittää dokumentti - mutta HTML-dokumentin voi oikein mainiosti esittää myös kokonaan ilman CSS:ää. Tämä johtuu siitä, että HTML:n elementeille on olemassa yhteinen, oletettu perusulkoasu: siis että h1 tulostetaan muusta tekstistä korostettuna ja näkyvämpänä kuin esim. h2 ja niin edelleen. Omissa XML-kielissä tätä pohjaa ei ole, vaan CSS:n tarjoama ulkoasuehdotus on ainoa ulkoasuehdotus. Tämä on ristiriidassa CSS:n alkuperäisten tavoitteiden kanssa. Ongelma konkretisoituu tietenkin selaimilla, jotka eivät CSS:ää tue - tai jotka eivät voi muuten toteuttaa käyttäjän ehdottamia ulkoasumäärityksiä. Niille jää silloin varsin vähän vaihtoehtoja lopputuloksen järkevään esittämiseen.


Jukka Korpela on kirjoittanut samasta asiasta, joskin jo jonkun aikaa sitten, artikkelin Computer-lehteen: Lurching Toward Babel: HTML, CSS, and XML (PDF-muodossa).

XML + XSLT = XHTML?

Valtaselainten viides sukupolvi toi XML-tuen koteihin, vaikkei sitä vielä moni tiedäkään. Hieman yllättäen se on tuonut myös jonkinlaisen XSLT-toteutuksen lähes joka mikrolle: siinä missä äskeisessä esimerkissä oli mahdollista julkaista XML:ää CSS:llä muotoiltuna, samoilla välineillä onnistuu myös se, että verkkosivujen tekijä julkaisee XML-datatiedoston ja XSLT-tyylitiedoston, joista selain itse väsää (X)HTML:ää (jota tietysti voi edelleenkin tyylitellä CSS:llä).

Tässä vältettiin pelkän CSS:n käytöstä aiheutunut ongelma siitä, etteikö lopputulos olisi luettava myös CSS-tuen puuttuessa: tuloksenahan on kaikkien taiteen sääntöjen mukainen XHTML-dokumentti, joka kyllä osataan näyttää oikein joka tapauksessa. Ongelmaksi jää se, että mitäs vanhempi (pelkkää HTML:ää ymmärtävä) selain tekee, kun vastaan tulee XML:ää ja XSL:ää? Valitettavasti ei mitään, ja niinpä myös XSLT-skriptien lähettäminen selaimille on tällä hetkellä varsin ongelmallista.

Silti XML:n ja XSLT:n yhteiskäyttö on oikea tie järkevään verkkojulkaisuun. Ratkaisevaa on vain se, että missä muunnos tehdään. Tällä hetkellä aika ei ole kypsä vielä mihinkään muuhun kuin XHTML:n lähettämiseen selaimille, joten on syytä muuntaa lähdedatana toimivat XML-dokumentit XHTML:ksi jo palvelimella. Tämän voi tehdä joko lennossa tai etukäteen, ihan omien valintojen ja käytössä olevan tekniikan ja kapasiteetin mukaan.

Yhteenveto: XML ja verkkojulkaisu 2002

Kuten yllä on esitetty, XML ja CSS ei ole järkevä tekniikka XML-muotoisten dokumenttien julkaisuun. Se voi toimia joissain tilanteissa, kun esim. intranetissä julkaistaan tilastomateriaalia, jonka siirtäminen HTML-muotoon olisi turhaa vaivaa - siis silloin, kun käyttäjäryhmä tunnetaan ja kaikilla tiedetään olevan riittävät tekniset valmiudet XML/CSS-yhdistelmän järkevään tulkitsemiseen.

XML ja XSLT ovat hyvä yhdistelmä, mutta oikea käyttötapa vaatii muunnosten tekemistä palvelinpäässä. Jos selaintuki jossain vaiheessa etenee sille tasolle, että XSLT-muunnoksia tuetaan käytännössä kaikissa selaimissa, tilanne on sitten erilainen. Tällä hetkellä muuntimet on kuitenkin vielä syytä asentaa palvelinpäähän.

Näistä parista teknisestä ongelmasta huolimatta XML:ssä on järkeä tulevaisuuden verkkojulkaisemisen kannalta. Sitä ei pidä ajatella HTML:n korvaajana, koska molemmille on selkeästi omat tonttinsa. XML-arkkitehtuuri mahdollistaa XHTML-dokumenttien laajentamisen (kuten muiden kielten upottamisen) ja helpottaa materiaalin julkaisemista useammassa ympäristössä. Nämä molemmat ovat tärkeitä etuja, jotka on syytä huomioida huomisen web-palveluita suunnitellessa.

Lisätietoja XML:stä?

Edellä oleva teksti oli vain suppea johdanto XML:n maailmaan. On tärkeää huomata, että tämän tekstin kirjoittamisessa tarkoituksena on ollut pääasiassa johdattaa käyttäjä ymmärtämään, mitä XML on - se, miten XML-dokumentteja tehdään ja miten niitä käytetään, on huomattavasti laajempi juttu, jota kannattaa opiskella erikseen tarpeen mukaan.

Jokainen mainituista tekniikoista ansaitsisi vähintään tämän mittaisen jutun tullakseen käsitellyksi edes suunnilleen kattavasti. Onneksi XML:stä on jo varsin paljon tietoa tarjolla: kirjakauppojen hyllyt notkuvat, ja netistäkin löytyy - ainakin jos osaa englantia. Ohessa muutama linkki hyville tiedon lähteille:

Jouni Heikniemi
19.2.2001

Tämä dokumentti kuuluu sivujeni osioon
Kirjalliset tuotokset / Tietotekniikka.