Tämä kirjoitus pyrkii lähinnä avaamaan erään olennaisen näkökulman HTML-kieleen, mutta tätä varten tarkastellaan yleisesti merkkauskieliä (markup languages). Erityisesti korostetaan rakenteisen eli kuvailevan (descriptive) ja proseduraalisen merkkauksen eroa sekä tarkastellaan HTML:ää tämän eron valossa.
Oletetaanpa, että olet lehden kirjeenvaihtajana jossakin kaukana, josta lähetät juttusi sähkeitse. Ja oletetaan, että tekstisi sellaisenaan sopii jutuksi, kunhan sen ulkoasu on sopiva. Jos sähköttäminen tuntuu kovin vanhanaikaiselta, niin lähes yhtä hyvin voimme ajatella, että käytettävissäsi on vain puhelin; sähkettä vastaavaan tilanteeseen tullaan, jos joku purkaa sanelemasi viestin tekstiksi. (Tai voisimme ajatella, että joudut lähettämään juttusi kännykällä tekstiviesteinä.)
Voitaisiin menetellä niin, että joku lehden toimituksessa oleva työkaverisi merkitsee tekstiisi vaikkapa korjauslukumerkinnöin, mikä kaikki on ladottava isommalla kirjasinlajilla, mikä teksti keskitettävä, mihin tulee kappaleenvaihdot, missä käytetään kursiivia tai ehkä petiittiä jne. Ammattitaitoinen latoja varmaan selviäisi sen jälkeen hommasta. Eräässä mielessä korjauslukumerkinnät, kuten sanan alleviivaus ja siihen liittyvä reunuksessa oleva merkintä "___ kurs." (kursivoidaan), muodostaa eräänlaisen merkkauksen, markup: tekstin yhteydessä esitettävä, mutta itse tekstiin kuulumaton merkintä, joka sanoo jotain tekstin esittämisestä tai tekstistä muutoin. Kyse on luonteeltaan proseduraalisesta merkkauksesta, eräänlaisesta käskystä suorittaa tekstille jokin toimenpide.
Mutta eikö olisi parempi, että voisit itse määrätä ladonnasta? Sinähän olet jutun tehnyt, joten tiedät paremmin, mikä sen tarkoitettu rakenne on, joten voit paremmin antaa ladontakäskyt. Sähkeessä tai sanelussa ei tietenkään voi käyttää korjauslukumerkintöjä. Eräs mahdollisuus olisi kuvata tekstin haluttu ulkoasu tekstin jälkeen tulevassa tekstissä, ihan normaalilla suomen kielellä tyyliin "ensimmäinen virke pääotsikoksi keskitettynä 26 pisteen fontilla, sitten kaksi virkettä ingressikappaleeksi 18 pisteellä, ...". Mutta tällöin tekstin osiin viittaaminen olisi varsin hankalaa.
Niinpä tuntuisikin luontevammalta käyttää tekstin sekaan kirjoitettua merkkausta. Koska senkin olisi oltava tekstiä, se pitäisi jotenkin erottaa varsinaisesta tekstistä. Oletetaan vaikka, että se kirjoitetaan sulkeisiin. Vaikkapa tähän tapaan:
(keskitä)(26 pistettä)Isojalka löytynyt Calisotasta(lopeta keskitys) (18 pistettä)Calisotan Ankkavuorella on tehty luotettavia havaintoja tähän asti taruolentona pidetystä isojalasta, (kursivoi)bigfoot(lopeta kursivointi). Isojalka muistuttaa ihmistä mutta on karvainen ja 2,5 metriä korkea. (normaaliteksti)(uusi kappale)Tiedemiehet ovat hämmentyneitä...
Tässä vaiheessa ehkä jo tulee mieleen, mitä sitten tehtäisiin, jos tekstiin itseensä haluttaisiin sulkumerkkejä. Tarvittaisiin jokin sopimus siitä, miten ilmoitetaan, että tämä sulkumerkki on oikea sulkumerkki eikä ladontakäskyn aloitus. Koska normaalitekstissä sulkeita esiintyy aika paljon, tästä seuraisi epämukavuutta. Niinpä esim. HTML:ssä käytetäänkin merkkauksessa sulkeiden () asemesta merkkejä <> kulmasulkujen tapaan.
Joissakin merkkauskielissä (esim. Unixissa käytetty
nroff)
käytetään sellaista menettelyä,
että kukin merkkaus on omalla rivillään; merkkausrivit erotetaan
normaaleista tekstiriveistä esimerkiksi siten, että merkkausrivi
alkaa aina pisteellä.
Tällöin merkkausta sisältävä tiedosto on helpompi käsitellä
ohjelmallisesti, mutta sitä on ihmisen ikävämpi kirjoittaa ja lukea
kuin rivirakenteeltaan vapaata merkkauskieltä. Rivirakenteen
vapaus toisaalta aiheuttaa sen, että merkkauksessa on
yksikäsitteisesti ilmoitettava sekä merkkauksen alku että sen loppu.
Kuvitteellisen esimerkkimme merkkaus olisi luultavasti latojan ymmärrettävissä aika helposti ja oikein. Mutta latojat ovat käyneet vähiin; tilalle on tullut tietokoneladonta. Ja tietokoneille asiat onkin esitettävä paljon täsmällisemmin kuin ihmisille. Tarkemmin sanoen merkkaus(kin) on tehtävä käyttäen erityistä sovittua merkintätapaa hyvin täsmällisten sääntöjen mukaan. Jos säännöt sanovat esimerkiksi että uusi kappale aloitetaan merkkauksella "(uusi kappale)", niin se merkitsee, että tietokone on ohjelmoitu suorittamaan kappaleenvaihto, kun se on lukenut juuri sellaisen merkkauksen. Ihminen luultavasti ymmärtäisi oikein, vaikka kirjoittaisimme sovitun merkkauksen sijasta "(uusi kpl)", mutta tietokoneelle se olisi vain tunnistamaton käsky.
Jotta täsmällisten sääntöjen määrittely ja toteuttaminen olisi helpompaa, pyritään yleensä esittämään ne formalisoidusti eli tarkkojen muotosääntöjen mukaan. Eräs tapa esittää sellaiset säännöt on käyttää erityistä kuvauskieltä, metakieltä. Tämä mahdollistaa sen, että on helpompi tehdä ohjelma, joka tarkistaa, että merkkaus noudattaa sääntöjä, siis eräänlainen merkkauskielen oikoluku. Mutta periaatteessa säännöt voitaisiin esittää myös luonnollisella kielellä, vaikkapa suomeksi, joskin niistä tulisi aika pitkiä silloin. Olennaista on, että on tarkoin määritelty, millaista merkkausta käytetään.
Kuvitteellisen esimerkkimme merkkaus on luonteeltaan aika puhtaasti proseduraalista, käskevää: se koostuu ikäänkuin käskyistä tai komennoista ohjelmalle, joka toteuttaa merkkausta. Esimerkiksi "(18 pistettä)" käskee vaihtamaan kirjasinlajia; voimme mielessämme kuvitella, miten ohjelma toimii ikäänkuin latoja, joka käskystä vaihtaa laatikkoa, josta se poimii kirjasimia. Merkkaus "(uusi kappale)" ei kuulosta samalla tavoin käskevältä, pikemminkin kuvailevalta, mutta olettakaamme, että sen on määritelty tarkoittavan esimerkiksi 'lopeta rivi, jätä tyhjä rivi'; silloin sitäkin voi sanoa käskyksi.
Kuvitteellisen esimerkkimme voisimme muuttaa todelliseksi HTML:ksi vain vaihtamalla merkkauksen toisennäköiseksi mutta rakenteeltaan aika tarkoin samaksi, erona tosin mm. se, että HTML:ssä ei määrätä fyysistä kirjasinkoko vaan vain suhteellinen koko (suhteessa johonkin erikseen määräytyvään asteikkoon):
<center><font size="+2">Isojalka löytynyt Calisotasta</font></center> <font size="+1">Calisotan Ankkavuorella on tehty luotettavia havaintoja tähän asti taruolentona pidetystä isojalasta, <i lang="en">bigfoot</i>. Isojalka muistuttaa ihmistä mutta on karvainen ja 2,5 metriä korkea.</font> <p>Tiedemiehet ovat hämmentyneitä...
Selaimesi esittäisi tämän näin:
Isojalka löytynyt Calisotasta Calisotan Ankkavuorella on tehty luotettavia havaintoja tähän asti taruolentona pidetystä isojalasta, bigfoot. Isojalka muistuttaa ihmistä mutta on karvainen ja 2,5 metriä korkea.Tiedemiehet ovat hämmentyneitä...
Proseduraalinen merkkaus on vuosikymmeniä vanha ja laajasti käytetty idea. Se mahdollistaa ulkoasun tarkan säätelyn, toki niissä rajoissa, jotka käytetyn merkkauskielen ilmaisuvoima asettaa. Jos ei ole merkkauskäskyä, joka vaihtaisi väriä, niin sitten ei voi käytellä värejä. Eri asia on, että sellaisiin asioihin ehkä voi vaikuttaa merkkauskielen ulkopuolella; esimerkiksi tulostamalla asiakirja värilliselle paperille saadaan tekstille värillinen tausta ilman mitään merkkausta. (Tämä kuulostaa naiivilta, mutta sillä on analogiansa Web-maailmassa: muuttamatta mitään HTML-dokumentissa voidaan sitä katsella erivärisiä taustoja käyttäen, vain muuttamalla selaimen asetuksia.)
Merkkauksen käyttö on monin tavoin ongelmallista:
<i> tarkoittaa kursivointia
(engl. italics)
Niinpä tekstinkäsittelyssä laajalti on siirrytty sitä varten kehitettyihin ohjelmiin, joille leimallista on WYSIWYG-periaate: What You See Is What You Get, näet mitä saat. Idea lienee nykyisin laajalti tunnettu: esimerkiksi tekstin kursivointi saatetaan hoitaa niin, että hiirellä "maalataan" tekstiosuus ja sitten valitaan valikosta "kursivoi". Kirjoittaja itse näkee tekstin heti kursivoituna. (Tosin käytännössä kyllä usein käy niin, että kun tekstin tulostaa paperille, se ei olekaan ihan sellainen kuin kuvaruudulla näytti, mutta se on oma ongelmakenttänsä.)
Tekstinkäsittelyohjelma kyllä tyypillisesti käyttää sisäisesti datarakennetta, jota voidaan pitää merkkauksena. Ja tavallaan myös toimintoa, jossa käyttäjä maalaa tekstin ja sitten määrää kursivoimaan sen, voidaan pitää eräänlaisena merkkauksena sitäkin, hiukan samantapaisena kuin alussa mainittu alleviivaus ja reunuksessa oleva ohje (tai esim. erilaisten alleviivausten käyttö eri kirjasinlajien osoittamiseen). Lisäksi tekstin siirrossa erilaisten tekstinkäsittelyohjelmien välillä käytetään usein sellaisia merkkauskieliä kuin RTF; niitä ei ole tarkoitettu ihmisten kirjoitettavaksi eikä luettavaksi, vaikka ne sinänsä ovatkin tekstiä ja sen seassa olevaa merkkausta. Tarvittaessa RTF-muotoisen dokumentin voisi vaikka sähköttää. Eikö näin ole hyvä? Eikö olekin parempi, ettei ihmisten tarvitse muistaa ja käyttää hankalaa merkkausta, vaan tietokoneohjelmat tekevät sen tarvittaessa? Tosin ihmisen on opeteltava ohjelman toiminnot, joita voidaan pitää eräänlaisena merkkauksena, mutta opettelua auttaa suuresti se, että voi heti nähdä, mitä mikin toiminto vaikuttaa.
Palataan alussa kuvattuun esimerkkitilanteeseen ja oletetaan, että lehtiyhtiön johdolta on tullut käsky: kaikki jutut on julkaistava paitsi painetussa lehdessä myös Internetissä siten, että ne voidaan lukea PSK-laitteella. PSK tarkoittaa "piuhaton saantikäytäntö", ja PSK-laite on taskuun mahtuva laite, jossa on neljäkymmentä merkkiä leveä, seitsemän riviä korkea näyttö, jossa on käytössä vain yksi kirjasinlaji mutta sentään 42 eri väriä. (Kaikki yhteydet todellisiin laitteisiin jätetään lukijan mielikuvituksen varaan.)
Ennen kuin olet ehtinyt tointua ajatuksesta, ilmoitetaan, että lisäksi jutut on julkaistava sellaisena palveluna, että määrätyllä tavalla puhelimella soittamalla voi kuunnella jutun. Sinun annetaan ymmärtää, että tämä on vasta alkua.
Mitä tehdä? Mitä ihmettä tehdä, kun jutun esitysmuoto sisältää erikokoisia kirjasimia ja kursivointia, joita ei kerta kaikkiaan voi käyttää? Tämä ongelma on edessä, olipa juttu sitten WYSIWYG-menetelmällä kirjoitettu tai proseduraalisella merkkauksella varustettua tekstiä; nehän ovat kaikkein olennaisimmilta osin sama asia: jutun ulkoasun tarkahko esitys. Pitääkö kaikki esittää yhtenä tekstipötkönä vain?
Eräs mahdollisuus on muuntaa käytetty proseduraalinen merkkaus tai sen vastine toiseksi proseduraaliseksi merkkaukseksi, joka sopii toisenlaiseen esitystilanteeseen. Esimerkiksi merkkaus "(uusi kappale)" voitaisiin puhe-esitystä varten korvata merkkauksella "(tauko)" - tai sitten olemassa oleva merkkaus voitaisiin vain tulkita eli toteuttaa uudella tavalla, esimerkiksi taukona, tai PSK-laitteella vaikkapa punertavan värin käyttönä.
Mutta olisiko se luonnollista ja käytännöllistä? Sen sijaan, että määrittelisimme, että esimerkiksi kirjasimensuurennus merkitseekin milloin jotakin erityistä väriä, milloin äänenvoimakkuuden tai äänensävyn määrätynlaista muuttamista, voisimme luontevammin siirtyä kuvailevaan eli rakenteelliseen merkkaukseen.
Aiemman esimerkkimme proseduraalinen merkkaus voidaan korvata kuvailevalla seuraavaan tapaan:
<h1>Isojalka löytynyt Calisotasta</h1> <p><strong>Calisotan Ankkavuorella on tehty luotettavia havaintoja tähän asti taruolentona pidetystä isojalasta, <em lang="en">bigfoot</em>. Isojalka muistuttaa ihmistä mutta on karvainen ja 2,5 metriä korkea.</strong></p> <p>Tiedemiehet ovat hämmentyneitä...
Tässä merkkauksella on kuvaileva luonne; se kuvaa dokumentin
loogisen rakenteen, ottamatta kantaa siihen, miten eri rakenneosat
pitäisi esittää. Tämän ansiosta se on luontevasti esitettävissä
eri esitystilanteissa valitsemalla kullekin rakenneosalle jokin
esitystapa. Esimerkiksi 1. tason otsikko (h1)
voidaan esittää isoa fonttia, poikkeavaa väriä tai painokasta,
hidasta lukutapaa käyttäen.
Seuraavassa on kaksi mahdollista tapaa esittää yllä oleva dokumentinpala. Esitysasu riippuu muun muassa siitä, missä määrin selaimesi tukee tyylisäännöstöjä (style sheets), sillä jälkimmäistä esitystä varten on kirjoitettu sellainen.
"Oletusarvoinen" esitys (huomaa, että tähänkin voi sisältyä tämän koko dokumentin mukana tulevan tyylisäännöstön vaikutus):
Isojalka löytynyt Calisotasta
Calisotan Ankkavuorella on tehty luotettavia havaintoja tähän asti taruolentona pidetystä isojalasta, bigfoot. Isojalka muistuttaa ihmistä mutta on karvainen ja 2,5 metriä korkea.
Tiedemiehet ovat hämmentyneitä...
"Tyylitelty" esitys:
Isojalka löytynyt Calisotasta
Calisotan Ankkavuorella on tehty luotettavia havaintoja tähän asti taruolentona pidetystä isojalasta, bigfoot. Isojalka muistuttaa ihmistä mutta on karvainen ja 2,5 metriä korkea.
Tiedemiehet ovat hämmentyneitä...
Erilaisia "tyyliteltyjä" esityksiä voidaan kehittää ääretön
määrä, sekä eri laitteiden ominaisuudet että käyttäjien
ominaisuudet ja mieltymykset huomioon ottaviksi.
Toisaalta kuvailevaa merkkausta voi käsitellä sellaisenaan,
aivan muussakin tarkoituksessa kuin sen näkyväksi esittämiseksi.
Dokumentteja voidaan esimerkiksi ohjelmallisesti analysoida niin,
että ohjelma kokoaa kunkin dokumentin tärkeimmät sanat, painottaen
otsikoita niiden tason mukaan, vahvasti korostettua tekstiäkin
(strong) aika paljon, yksinkertaista korostustakin
(em) enemmän kuin normaalitekstiä. Nykyisin Webissä
toimivat hakujärjestelmät ("hakukoneet") jossain määrin toimivat
tähän tapaan, joskin ajatuksen soveltamista rajoittaa se, että
kuvailevaa merkkausta ei vielä käytetä kovinkaan johdonmukaisesti.
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.
SGML-standardin liite (annex) A, Introduction to Generalized Markup, sisältää lyhyehkön, suhteellisen helppolukuisen johdatuksen kuvailevan ja proseduraalisen merkkauksen eroihin. Se kuvaa kuvailevaa (descriptive) merkkausta, tässä nimellä generalized markup, seuraavasti:
Generalized markup is based on two novel postulates:
- Markup should describe a document's structure and other attributes rather than specify processing to be performed on it, as descriptive markup need be done only once and will suffice for all future processing.
- Markup should be rigorous so that the techniques available for processing rigorously-defined objects like programs and data bases can be used for processing documents as well.
Kuvaileva merkkaus sopii huonosti yhteen "mitä näet, sitä saat" -ajatuksen kanssa. Ei ole mahdollista nähdä sitä, mitä saadaan, koska se on olemukseltaan näkymätöntä, abstraktia, vaikka sillä voi olla erilaisia näkyviä (ja kuultavia) esitysasuja. Periaatteessa voitaisiin toki tehdä niin, että käytetään ohjelmaa, jossa voidaan tekstinkäsittelyohjelmien tapaan muuttaa dokumentin asua ja suuntautua ajattelemaan niin, että esimerkiksi lihavointi ei merkitse lihavointia vaan abstraktia korostusta. Jos joku siihen pystyy, niin mikäs siinä; mutta sitten ohjelman pitäisi myös tuottaa kuvailevaa merkkausta, ja sellaisessa ajattelussa pitäisi olla johdonmukainen. Tuntuisi kuitenkin siltä, että työskentely vain yhden näkyvän esitysmuodon parissa on omiaan ohjaamaan ajatukset liikaan konkreettisuuteen. Tässä mielessä merkkauksen kirjoittaminen helpottaa asioita verrattuna "mitä näet, sitä saat" -työskentelyyn.
Kuten esimerkeistä on jo jossain määrin ilmennyt, HTML:ssä
on mahdollisuus sekä kuvailevaan että proseduraaliseen
merkkaukseen. Itse asiassa saman jutun voi kirjoittaa molemmilla
tavoilla, esimerkiksi otsikot h1- yms. elementeillä
taikka font-elementeillä.
Osa ilmaisuista olisi kuitenkin samoja, koska merkkausta
voidaan tulkita kummallakin tavalla. On itse asiassa aika
olennaista, kumman tulkinnan mukaan sellaisia kaksitulkintaisia
rakenteita käytetään.
Esimerkiksi merkkauksen <hr> looginen merkitys
on 'aiheen vaihto' (change of topic) eli se sopii erottamaan
dokumentin olennaisesti erilaisia osia toisistaan. Alusta
alkaen HTML:n kuvauksissa on viitattu tähän loogiseen merkitykseen
muun muassa mainitsemalla, että dokumentin ääneen esittämisessä
<hr>:n esitystapana voisi olla tauko.
Toisaalta itse merkkauksen nimi johtuu sanoista
horizontal rule 'vaakaviiva', ja usein sitä käytetäänkin
sen kummemmin ajattelematta, kun vain jostain syystä halutaan
vaakaviiva.
Merkkauksen <p> alkuperäisin merkitys oli
'kappaleen vaihto', analogisesti rivinvaihdon
<br> kanssa.
Kuitenkin jo varhain HTML:n historiassa
omaksuttiin kanta, jonka mukaan
<p>
aloittaa kappaleen.
Ajatuksena on, että kappale on
looginen rakenneosa, rivi ei niinkään.
Eroa tämän ja aiemman ajatuksen välillä voi olla vaikea havaita,
mutta sillä on käytännöllistäkin merkitystä. On useassa suhteessa
olennaista, onko otsikon jäljessä olevan tekstin
edessä kappaleen aloitusta tarkoittava merkkaus vai ei.
Monet Web-sivujen tekijät suosivat merkkausta, jossa loogiset
kappaleet erotetaan toisistaan <br>-merkkauksella
siten, että kyseisen merkkauksen perässä on muutama sellainen
välilyönti (ns. sitova välilyönti), jotka saavat aikaan tekstin
ensimmäisen rivin pienen sisennyksen. Taustalla on, että
suositut selaimet tyypillisesti näyttävät kappaleiksi merkatut
osat niin, että niiden välissä on tyhjän rivin verran tilaa,
ja tätä monet eivät pidä hyvänä. Mainitulla
<br>-merkkaukseen perustuvalla tekniikalla
saadaan aikaan, ettei sellaista tyhjää tilaa ole, vaan
kappale vain alkaa pienellä sisennyksellä kuten useimmiten
kirjoissa. Onko tässä järkeä? Joka tapauksessa siitä on se haitta,
että merkkaus ei vastaa loogista rakennetta. Jos
tekstiä vaikkapa analysoitaisiin ohjelmalla, joka tekee
luettavuusarvion, olettaen merkkauksen vastaavan rakennetta,
tuloksena olisi musertava arvio: ei kappalejakoa, eli valtavan
pitkä kappale, kuin muinoin tuomioistuimen päätöksissä,
luettavuus siis surkea.
Lyhyesti voitaisiin HTML-kielen historiaa luonnehtia edellä esitetyn valossa näin:
font); mukaan otettiin lähinnä sellaiset piirteet,
jotka oli toteutettu Netscapen ja IE:n uusimmissa versioissa
edes jotenkuten samalla tavoin
Taulukot, jotka tulivat mukaan HTML 3.2:ssa,
ovat erikoisasemassa sikäli, että ne voidaan ymmärtää joko
kuvailevaksi, rakenteelliseksi merkkaukseksi tai
proseduraaliseksi ulkoasua, "taittoa", sääteleväksi merkkaukseksi.
Taulukoihin liittyvän merkkauksen kuvaus HTML:ssä on laaja ja sekavakin
lähinnä sen takia, että mukana on niin paljon proseduraalisen
merkkauksen mahdollisuuksia. Toisaalta esimerkiksi taulukon
ulkoasuun vaikuttaminen on käytännössä lähes välttämätöntä
usein silloinkin, kun niitä haluttaisiin käyttää puhtaasti
kuvailevina, rakenteellisina. Esimerkiksi numeerista dataa
sisältävä taulukko näyttää oudolta, jos luvut eivät ole siististi
allekkain; ja tämä täytyy käytännössä tehdä proseduraalisella
merkkauksella (esim. align-määritteellä) tai vastaavalla,
koska taulukkokäsitteestä puuttuu mahdollisuus sellaisen
kuvailevaan merkkaukseen, joka sanoisi esimerkiksi "tämä sarake
sisältää numeerista dataa".
Kaikenlaista merkkausta, mutta erityisesti kuvailevaa merkkausta varten tarvitaan merkkauskielen määritelmä. Se taas on esitettävä jollakin kielellä. Luonnolliset kielet sopivat siihen aika huonosti, joten on kehitetty erilaisia formalisoituja kieliä, joita käytetään muiden kielten määrittelemiseen - metakieliä.
Merkkauskielten, myös HTML:n, määrittelyyn on yleisesti käytetty SGML-metakieltä. On huomattava, että tällöin on kyse vain muodollisesta rakenteesta, syntaksista. Merkkauksen varsinainen merkitys, oli se sitten käskevää (proseduraalista) tai kuvailevaa (rakenteellista), määritellään luonnollisella kielellä, tavallisimmin englanniksi. Esimerkiksi HTML:n SGML-kielinen määrittely sisältää säännön
<!ELEMENT UL - - (LI)+ -- unordered list -->
Tämä määrittelee, määrättyä tiivistä merkintätapaa käyttäen,
että kielessä voi käyttää ul-elementtiä
siten, että elementin sisältönä on yksi tai useampia
li-elementtejä, eikä mitään muuta.
Teksti "unordered list" on vain kommenttia eikä kuulu syntaksiin,
vaan se on suppea luonnollisella kielellä esitetty kuvaus
ul-elementin
merkityksestä.
Elementti
tarkoittaa dokumentin rakenneosaa,
joka koostuu aloitus- ja lopetusmerkkauksesta
ja niiden välissä olevasta sisällöstä. Esimerkki
ul-elementistä:
<ul> <li>yksi</li> <li>kaksi</li> </ul>
SGML-kielinen määrittely kertoo muun muassa sen, millä tavoin
elementtejä rakenneosia voi olla sisäkkäin. Esimerkiksi
ul-elementin sisällä ei saa olla muuta kuin
li-elementtejä. Tämä helpottaa kielen automaattista
käsittelyä eri tavoin samoin kuin rakenteiden merkitysten määrittelemistä;
tässä yhteydessä riittää merkityksen määrittelemiseksi sanoa, että
ul-elementti on numeroimaton lista alkioita,
jotka esitetään sen sisällä li-elementeillä.
Tämä ei varsinaisesti puutu esitysasuun, joskin pieni viittaus
siihen suuntaan on: kyseessä on numeroimaton lista
vastakohtana numeroidulle. Tässäkin asiassa on siis pientä
lipsuntaa puhtaasti kuvailevasta merkkauksesta.
|
Joka tapauksessa
eräs |
Esimerkki
|
Täsmällisellä metakielisellä syntaksin määrittelyllä voidaan saavuttaa seuraavat edut:
SGML-kieli, Standard Generalized Markup Language, kehitettiin kauan ennen HTML:ää ja Webiä. Sitä on myös laajasti käytetty määrittelemään erilaisia dataformaatteja eri sovelluksiin. Tältä kannalta oli luonnollista, että sitä ruvettiin käyttämään myös HTML:n syntaksin määrittelyyn. Tosin voidaan sanoa, että käytännössä ensin kehiteltiin kielen ensimmäinen versio ja sitten ruvettiin sovittamaan sitä SGML:n puitteisiin.
Käytännön kannalta on mainittava, että Web-selaimet ovat useissa keskeisissä suhteissa SGML-rajoitteisia. Ne eivät suinkaan käsittele dokumentteja kaikilta osin edes SGML:n perussääntöjä noudattaen. Ne eivät yleensä edes tee alimman tason jäsennystä (parsing) käyttäen yleisiä SGML-pohjaisia välineitä vaan ad hoc -koodia (ns. tag soup processing). Tämä ei kuitenkaan ole peruste rikkoa sääntöjä, pikemminkin päinvastoin. Kokemus osoittaa, että sääntöjen rikkominen johtaa ongelmiin; vaikka selain on lepsusti tehty, se selviää varmemmin sellaisesta dokumentista, joka on tiukasti tehty. Ks. dokumenttia 4 Reasons to Validate your HTML, joka selostaa esimerkein, miten jokainen uusi Netscapen versio on tehnyt joukon aiemmin "toimineita" sivuja toimimattomiksi, koska ne rikkoivat SGML:n sääntöjä ja tavallaan luottivat siihen, että Netscapekin rikkoo.
XML:ää mainostetaan "laajennettavana merkkauskielenä" - johtuuhan sen nimikin sanoista eXtensible Markup Language - ja HTML:n seuraajana ja ties minä. Tällä on omat syynsä. Todellisuudessa XML on SGML:n voimakkaasti yksinkertaistettu versio. Teknisesti XML on määritelty SGML:n pohjalta, sen "profiilina" (profile).
Taustalla on ajatus siitä, että uusien merkkauskielten määrittely sujuu paremmin, kun käytettävä metakieli on yksinkertaisempi, helpompi opetella ja osata. SGML on itse asiassa erittäin mutkikas, siitä huolimatta, että se on vain merkkauskielten syntaksin määrittelemisen väline.
Yksinkertaisuudella on merkitystä myös sikäli, että koska XML asettaa paljon enemmän rajoituksia merkkauskielelle, niin XML-syntaksin mukaista merkkauskieltä on helpompi ja nopeampi käsitellä ohjelmallisesti.
Yhtenä ideana on myös se, että XML:ää käytettäessä ei merkkauskielen syntaksia tarvitse erikseen määritellä. Eräässä mielessä voidaan kirjoittaa dokumentti suoraan XML:llä, käyttäen millaista merkkausta haluaa, siis vaikka tyyliin
<munjutska kieli="korso"><kewl taso="kova">...
ja tällaista XML-dokumenttia lukevan ohjelman edellytetään käsittelevän sitä, vaikka merkkauskieli on vain implisiittisesti määritelty sen kautta, miten merkkauksen alkioita on käytetty.
Herää kysymys, missä pihvi. Olipa merkkauskieli määritelty kunnolla tai vain implisiittisesti, kyse on vain syntaksista. Se, mitä merkkaus tarkoittaa, olisi kuvattava erikseen. Ja se onkin tyypillisesti paljon hankalampi ja isompi asia kuin pelkän syntaksin määrittely. Sama koskee sellaisten ohjelmien, esimerkiksi selainten, tekemistä, jotka jotenkin käsittelevät (vaikkapa näyttävät) merkkauskielellä kirjoitettuja dokumentteja.
Eräs yleinen lähestymistapa on ajatella, että merkkauksen merkitys määritellään tyylisäännöstöillä (style sheets), jotka kuvaavat, miten mikin merkkaus tulee fyysisesti esittää. Merkkauksen merkitykseksi siis ajatellaan se, miltä se näyttää (ja tyypillisesti nimenomaan ja vain tavanomaisen tietokoneen kuvaruudulla esitettynä), eli se, miten se ohjaa tietokonetta esittämään dokumentin. Tässä vaiheessa on toivottavasti selvää, että tämä merkitsee erittäin selvästi paluuta proseduraaliseen merkkaukseen, vaikka merkkauksessa käytetyt sanat voivat olla viittavinaan dokumentin loogiseen rakenteeseen. - Teoriassa voidaan toki tehdä eri tyylisäännöstöjä erilaisia esitystilanteita varten (esim. graafinen esitysmuoto, tekstimuoto, äänimuoto). Käytännössä sellainen jäänee harvinaisuudeksi.
XHTML 1 on HTML 4 siten, että sen syntaksi
on kuvattu XML:llä. Tämä merkitsee, että syntaksi noudattaa
rajoitetumpia sääntöjä; esimerkiksi eräät lyhennysmerkinnät
(esim. multiple) eivät kelpaa (vaan on kirjoitettava
esim. multiple="multiple").
Sekaannuksia on aiheutunut siitä, että sivuntekijät ovat
ruvenneet vähittäisesti siirtymään HTML 4:stä
XHTML:ään. Esimerkiksi on jostakin opittu kirjoittamaan joihinkin
tägeihin vinoviiva, esim. <br /> eikä
<br>. Tämä kuitenkin vaatisi, että dokumentti
on kokonaisuudessaan XHTML-sääntöjen mukainen. Ks.
selostusta Empty elements in SGML, HTML, XML, and XHTML.
Jukka Parviainen on kirjoittanut hyvän lyhyehkön tiivistelmän SGML-, HTML-, ja XML-kielten eroja ja yhtäläisyyksiä.
Seuraavaksi voi perehtyä tarkempaan joskin vielä aika yleisluonteiseen kuvaukseeni SGML-kielestä, jos SGML:n tai XML:n oppiminen on tarpeen.
Proseduraalisen ja kuvailevan merkkauksen eroa käsittelee hyvin Dmitri Kirsanovin Procedural and Descriptive Markup. Syvällisempi esitys on Robin Coverin SGML: A Textual Representation for Information Structure; Part 2: The Axiological Foundations of SGML (NOC,16.5).
Jos taas käytännöllisempi ote on ajankohtaisempi, voi aloittaa Web-julkaisemisen oppaassa esittämääni kuvaukseen HTML-kielen perusteista, jossa on linkkejä eteenpäin.