Elementtejä vai määritteitä?


Johdanto

Yleinen rakennemäärittelyjä suunnittelevien tekemä kysymys on "Pitäisikö tässä käyttää elementtiä vai määritettä?" Tämä ongelma tulee vastaan vähän väliä ja usein on vaikeaa löytää ratkaisua, joka olisi selvästi toista parempi.

Elementtien ja määritteiden välillä ei ole selvää työnjakoa. Yleensä niiden käyttötavat riippuvat enemmän suunnittelijan mieltymyksistä ja yleisistä tavoista kuin tietyn ratkaisun ehdottomasta paremmuudesta. Yksi klassinen esimerkki tästä on kirjan nimen merkitseminen:

Elementtinä Määritteenä
<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.

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:

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).


Sivua on edellisen kerran päivitetty: 07.02.2000.
Kommentteja voi lähettää Henri Ruinille osoitteeseen ruini@cs.helsinki.fi.