Elementtejä vai määritteitä?

<kirja>
    <nimi>Neuromancer</nimi>
    ...
</kirja>

<kirja nimi="Neuromancer">
    ...
</kirja>

Pelkästään edellisen lyhyen esimerkin perusteella on mahdoton sanoa kumpi ratkaisu on parempi. Toisaalta ratkaisutavalla ei välttämättä edes ole mitään merkitystä. Seuraavissa kappaleissa tarkastellaan elementtien ja määritteiden käyttöä, suhteita ja ominaisuuksia vähän tarkemmin.

Toiselta sivulta löytyy joitain esimerkkejä elementtien ja määritteiden käytöstä.

Ratkaisuperusteet

Valintaa vaikuttavia seikkoja ovat mm.

• itse kuvattava tietosisältö
  
• tietoa käsittelevät sovellukset
  
• kokonaisuus
  
• yleiset tavat
  

Kuvattava tieto

Valintaan elementtien ja määritteiden käytön välillä vaikuttavista asioista ehdottomasti tärkein on itse sisältö eli kuvattava data. Ikävä kyllä se on samalla myös laajin ja tulkinnanvaraisin asia. Sisältöä voidaan katsoa useasta näkökulmasta, esimerkiksi:

• Rakenteisuus. Määritteiden arvoilla ei XML:n kannalta ole minkäänlaista rakennetta. Toki arvoille voidaan suunnitella rakenne, jonka varta vasten tehdyt omat sovellukset osaavat lukea ja ymmärtää. Tällöin kuitenkin menetetään siirrettävyys sovellusten välillä, sillä muut XML-määrittelyä noudattavat sovellukset eivät pysty ymmärtämään tätä rakennetta.

  Elementit sen sijaan muodostavat puumaisen rakenteen, joka on yhteinen kaikille XML-sovelluksille. Elementtien rakenteisuudesta on hyötyä esimerkiksi silloin, kun sisällön pitäisi esiintyä tietyssä järjestyksessä (esimerkki), sillä elementtien järjestys voidaan määrätä mutta määritteiden ei.

• Datan liittyminen ympäristöönsä. Elementtejä kannattaa käyttää silloin kun niiden sisältö on oleellinen osa ympäröivää elementtiä (esimerkki). Yksi hyvä tuntomerkki tällaiselle on poistaa merkkaus ja lukea sisältö. Mikäli sisältö muodostaa järkevän kokonaisuuden, kuuluu se tiiviisti ympäröivän elementin sisältöön ja on syytä käyttää elementtiä määritteen sijaan.

  Määritteiden käytölle hyvänä peukalosääntönä voidaan pitää niiden - nimensä mukaisesti - ominaisuutta määrittää ja kuvata elementin sisältöä (esimerkki). Määritteet voidaan myös ajatella adjektiiveiksi, jotka kertovat lisätietoja elementeistä (jotka puolestaan voidaan mieltää substantiiveiksi). Jos data antaa jotain lisätietoa elementistä tai sen sisällöstä mutta ei kuitenkaan kuulu varsinaiseen sisältöön, on kyseessä niin sanottua metatietoa (eli tietoa tiedosta), joka sopii hyvin määritteissä käytettäväksi (esimerkki). Määritteiden avulla voidaan esimerkiksi luokitella 'viesti'-elementin sisältö 'varoitus'-, 'vaara'-, 'huomio'-tyyppisiksi:

  <viesti tyyppi="varoitus">Ei lasten ulottuville!</viesti>
  <viesti tyyppi="vaara">Korkeajännite!</viesti>

• Datan (pieni) arvojoukko. Mikäli data itse asiassa on pieni joukko tunnettuja arvoja, kuten edellä olevan esimerkin 'varoitus', 'vaara' ja 'huomio', on syytä käyttää määritteitä. Tällöin rakennemäärittelyssä voidaan rajata määritteeen saamat arvot ja esimerkiksi XML-editorit ja -jäsentimet voivat tarkastaa (validoida) arvot automaattisesti.

  Rakennemäärittelyt eivät tarjoa mitään keinoja rajoittaa elementtien tekstisisältöä, joten elementissä edellisten arvojen lisäksi jäsentimet hyväksyisivät myös vaikkapa 'runo'- ja 'muistiinpano'-arvot. Tietenkin ulkopuolinen sovellus voi tarkastaa myös elementtien arvot, mutta silloin menetetään siirrettävyys XML-sovellusten välillä ja monimutkaistetaan toteutusta.

  Määritteiden arvojen luettelointi toimii ainoastaan dokumenteissa, jotka validoidaan (eli joissa on rakennemäärittely) - pelkästään hyvinmuodostetussa dokumenteissa tarkastukseen ei voi luottaa. Luettelointi myös menettää etunsa, mikäli lueteltavia arvoja on paljon: pitkä lista tekee rakennemäärittelystä vaikeamman ylläpitää ja editorit tuntuvat olevan huonoja käsittelemään pitkiä listoja. Tällöin voi olla viisaampaa edelleen käyttää määritteitä, mutta jättää arvot luettelematta.

• Oletusarvot. Oletusarvot liittyvät osaltaan edelliseen kohtaan, jossa käsiteltiin lueteltuja arvoja. Joissakin tapauksissa datassa voi olla jokin tietty usein esiintyvä arvo, jota halutaan käyttää oletusarvona. Tällöin ainoa vaihtoehto on laittaa data määritteeksi, sillä elementeille ei XML:n keinoin ole mahdollista antaa oletusarvoja.

  Oletusarvojen hyvä puoli on, että sovellukset huolehtivat valideissa dokumenteissa niistä automaattisesti, jolloin käyttäjälle jää vähemmän työtä ja muistettavaa.

Nämä eivät varmastikaan ole ainoa näkökulmat datasisällön luonteeseen, sillä erilaisella informaatiolla on aina omat ratkaisua painottavat käyttötapansa ja tarkoituksensa. Lisäksi ihmiset katsovat asioita eri tavalla. Esimerkiksi ohjelmoijille saattaa olla helppoa ajatella elementtejä olioina ja määritteitä olioiden sisäistä tilaa kuvaavina muuttujina. Graafikot näkevät elementit ehkä ruudulla näkyvinä visuaalisina objekteina, eikä määritteillä ole heille mitään käyttöä. Jokainen luonnollisesti haluaa käyttää elementtejä ja määritteitä oman sisäisen mallinsa mukaisesti eli rakennemäärittelyä suunniteltaessa on otettava huomioon myös käyttäjäryhmien tottumukset. Tärkeintä on kuitenkin löytää ne kaikista oleellisimmat piirteet, jotka määräävät tiedon käyttöä ja jotka valittavan esitystavan on mahdollistettava.

Sovellukset

Vaikka sovellusten huomioon ottaminen rakennemäärittelyä suunniteltaessa on XML:n perusajatusten vastaista, joutuu käytännössä usein tekemään kompromisseja voidakseen käyttää haluamaansa toiminnallisuutta. Sovellukset voivat siten vaikuttaa voimakkaastikin lopulliseen rakennemäärittelyyn.

Monet sovellukset (esimerkiksi XML-editorit) käsittelevät elementtejä ja määritteitä loogisesti eri tavalla: elementit näytetään automaattisesti (englanniksi käytetään termiä push), mutta määritteet käyttäjä joutuu hakemaan itse (pull). Useissa editoreissa tämä näkyy esimerkiksi siten, että elementtien sisältöä voidaan muokata suoraan editointi-ikkunassa, mutta määritteiden käsittely tapahtuu erillisessä ikkunassa.

Sovellukset voivat vaikeuttaa elementtien tai määritteiden käsittelyä huomattavasti, mikäli ne ovat enemmän kallistuneet toisen ratkaisun kannalle. Jos käyttäjä muokkaa määritteitä huomattavasti vähemmän kuin elementtejä, ei edellisessä editori-esimerkissä mainittu ylimääräinen vaiva määritteiden käsittelyssä ole kovinkaan suuri. Toisaalta - käsittelytavasta riippuen - erot voivat helposti kasvaa hyvinkin merkittäviksi. Esimerkiksi ohjelmointirajapinnoissa vaikeammin toteutettavan ratkaisun käyttäminen tuo mukanaan enemmän työtä ja virhemahdollisuuksia.

Kokonaisuus

Valitsi rakennemäärittelyn suunnittelija ratkaisunsa millä perusteella tahansa, on ratkaisusta riippumatta muistettava yhtenäisyys läpi koko rakennemäärittelyn. Erityisen tärkeää yhtenäisyys on silloin, kun käytössä olevia rakennemäärittelyjä on useita. Elementtien ja määritteiden käyttäminen sekaisin lähes samankaltaisessa tarkoituksessa tekee rakennemäärittelyjen ymmärtämisen, käytön ja ylläpidon paljon yhtenäistä käyttötapaa hankalammaksi.

Rakennemäärittelyn monimutkaisuus ja yhtenäisyyden puute ei välttämättä ole lainkaan selvä tai tärkeä itse suunnittelijalle, joka tuntee rakennemäärittelynsä perinpohjaisesti. Ongelmat tulevatkin vastaan käyttäjillä, jotka tuottavat rakennemäärittelyn mukaisia dokumentteja, ja ohjelmoijilla, joiden sovellukset käsittelevät dokumentteja.

Rakennemäärittelyt eivät myöskään ole ikuisesti muuttumattomina pysyviä olioita vaan niitä päivitettään ja muutetaan, eikä päivityksistä huolehtiva henkilö välttämättä olekaan rakennemäärittelyn alkuperäinen tekijä. Myös päivittäjän on opeteltava ja ymmärrettävä rakennemäärittelyn perusajatukset hyvin, jotta hän osaa tehdä siihen oikeat muutokset. Kannattaa siis rakennemäärittelyä tehdessä ottaa normaalikäytön lisäksi myös tulevaisuus huomioon: hyvä ja yhtenäinen rakennemäärittely helpottaa myös sen parissa toimivien ihmisten työntekoa ja rakennemäärittelyn jatkokehitystä.

Yleiset tavat

Erilaisia rakennemäärittelyjä on kehitetty lukuisia ja niiden sivutuotteena on syntynyt joitakin yleisesti käytettyjä tapoja. Eräs selvin ja hyvin usein esiintyvä tapa on URL:n (tai laajemmin URI:n) sijoittaminen määritteeseen, mikäli sillä on tarkoitus viitata johonkin dokumenttiin, dokumentin osaan, kuvaan, jne. Tätä on käytetty mm. HTML-määrittelyssä IMG-elementin kuvaviittauksiin tai A-elementeissä hypertekstilinkkeihin. Kuitenkaan tälle tavalle ei XML:n tekniikan kannalta ole mitään erityistä syytä, sillä URL voisi ihan yhtä hyvin olla elementin sisällä:

<IMG>http://www.helsinki.fi/u/ruini/structure/xml/images/suhteet_1.gif</IMG>

tai

<A>
    <HREF>http://www.helsinki.fi/u/ruini/structure/xml/perus/attr_vs_elem.html</HREF>
    <NAME>määritteet ja elementit</NAME>
</A>

Vaikka periytyneet tavat voivat vaikuttaa kummallisilta, on yleensä on hyvä miettiä useammankin kerran ennen kuin päättää kulkea omia polkujaan. Nimittäin yksi hyvin painava syy yleisten tapojen puolesta on olemassa olevat sovellukset ja lähdekoodit - on paljon helpompaa ja halvempaa hyödyntää valmiita sovelluksia tai koodia, kuin tehdä niitä itse alusta lähtien.

Yhteenveto

Loppujen lopuksi valinta elementtien tai määritteiden käytöstä riippuu niihin tallennettavan tiedon käyttötarkoituksesta ja tietoa käsittelevistä sovelluksista. Usein oikeaa tai selvästi parempaa vastausta ei ole olemassa ja joskus on syytä käyttää kumpaakin menetelmää yhdessä. Rakennemäärittelyn suunnittelijan on valittava useista peukalosäännöistä ja ohjeista itselleen ja omaan käyttötarkoitukseensa sopivat tai koostaa kokonaan omat sääntöönsä. On vain muistettava, etteivät säännöt saa olla liian tiukat, vaan niiden on joustettava käsiteltävän datan mukaisesti.

Tässä on käsitelty elementtejä ja määritteitä niiden mahdollisuuksien mukaan, mitä nykyinen XML-määrittely tarjoaa. Tulevaisuudessa Schema-määrittely tai SML voivat muuttaa painotuksia huomattavastikin.

Lisätietoja aiheesta (englanniksi) löytyy Robin Coverin SGML/XML-sivuilta, jonne on koottu asiantuntijoiden mielipiteitä eri käyttötavoista. Sivut kannattaa ehdottomasti lukea, mikäli valinta määritteiden ja elementtien välillä osoittautuu hankalaksi: SGML/XML: Using Elements and Attributes (http://www.oasis-open.org/cover/elementsAndAttrs.html).