Claus Huitfeldt: Tekster og tekstkoding

1.1.1 Kodesystemer er systemer for merking av elektronisk tekst. Derfor kalles de ofte også "merkesystemer", og det å kode en tekst kalles gjerne å "merke" den. På engelsk snakker man like ofte om markup som om encoding. [1]

1.1.2 De fleste brukere av datamaskiner har stiftet bekjentskap med kodet tekst, kanskje uten å være klar over det. F.eks. er de fleste dokumenter som finnes på World Wide Web (Web) kodet i HyperText Markup Language (HTML). Programmer som benyttes til å lese HTML-kodet tekst (såkalte "Weblesere" [2]) gir oftest brukeren anledning til å se det som gjerne kalles tekstens "kilde" eller "kildekode". Velger man denne muligheten, kan man istedet for overskriften ovenfor f.eks. få se noe slikt som dette:

1.1.3 Kodene utgjøres av det innledende merket <H2> og det avsluttende merket </H2>, som betyr at strengen mellom det innledende og det avsluttende merket er et element av typen overskrift (H2 for "Heading" på nivå 2). Programmer som viser HTML-tekster "vet" at slike overskrifter skal trykkes med fete typer i stor skrift på egen linje med ekstra "luft" over og under, og gir dem derfor også dette utseendet på skjerm og papir.

1.1.4 Med et annet kodesystem, TEI [3], kan man kode den samme overskriften slik:

1.1.5 I et tredje kodesystem, MECS [4], kan kodingen av den samme overskriften se slik ut:

1.1.6 Dette er tre forskjellige måter å kode samme overskrift på, likevel kan de alle gi samme synlige resultat på skjerm og papir. Hvorfor representeres tekster på denne indirekte og tilsynelatende tungvinte måten? For besvare dette spørsmålet må vi først ta for oss noen grunnleggende trekk ved elektronisk tekstbehandling.

1.2.1 Man kan hevde at den norske betegnelsen "datamaskin" er mer treffende enn den engelske "computer" (regnemaskin), ettersom datamaskiner ikke bare kan behandle tall men også andre datatyper som tekst, lyd og bilder. Men man kan også hevde at den engelske betegnelsen gir et bedre uttrykk for datamaskinens opphavlige bruk — for i begynnelsen ble datamaskiner bare brukt til å behandle numeriske data.

1.2.2 Nesten alt som idag produseres av trykt tekst har på et eller annet stadium vært innom en datamaskin. Datamaskinen spiller i de fleste tilfelle en vesentlig rolle i alle stadier på tekstens vei fra forfatter til mottaker: Den benyttes som redskap både til å skape, redigere, lagre, reprodusere, distribuere, presentere, manipulere og analysere tekster.

1.2.3 Selv om den tid er forbi da datamaskiner bare kunne brukes til tallbehandling, kunne man være fristet til å si at også dagens datamaskiner i bunn og grunn bare behandler tall. Datamaskiner er digitale — de minste informasjonsbitene i alle edb-baserte representasjonssystemer er representert ved enheter, bits, som kan være i en av to mulige tilstander. Disse to mulige tilstandene representerer konvensjonelt tallene 0 og 1, som i totallsystemet kan uttrykke et hvilket som helst tall. Det er interessant å merke seg at de to tilstandene like gjerne kan sies å representere de to sannhetsverdiene "sann" og "usann". Slik sett kan datamaskiner like gjerne betraktes som "logiske" maskiner som som tallbehandlere.

1.2.4 Ved å bunte bits sammen i bytes, og ved å få datamaskinen til å behandle bytes snarere enn bits som grunnenheter på et visst nivå, kan man representere flere tegn enn 0 og 1 — 2 bits pr byte gir 4 tegn pr byte, 3 gir 8 osv, slik at i f.eks. 8-bits systemer kan hver enkelt byte representere en hvilken som helst av 256 diskrete verdier.

1.2.5 Når datamaskiner brukes til tekstbehandling, representerer bytes alfanumeriske tegn, ikke tall. Det engelske alfabetet inneholder 26 tegn. I og for seg kan man altså greie seg med 5-bits systemer (32 tegn) — men da blir det bare plass til de 26 bokstavene i det engelske alfabetet og noen spesialtegn.

1.2.6 Selv 6-bits systemer (64 tegn) gir bare plass til 26 små + 26 store bokstaver + tallene = 62 tegn. Derfor vil man i slike systemer i praksis bare bruke store bokstaver, tall, setnings- og spesialtegn. Skillet mellom store og små bokstaver blir representert ved kombinasjoner av store bokstaver og setnings- eller spesialtegn.

1.2.7 Thesaurus Lingua Graeca (TLG) er et eksempel på et stort tekstkorpus som er bygget opp på denne måten — bokstavene i det greske alfabetet er her representert ved konvensjoner for kombinasjon av store latinske bokstaver og spesialtegn. TLG har fått så stor utbredelse og er så godt etablert at tekstkorpuset fremdeles distribueres og benyttes i dette formatet, og programvare som leser tekst i dette formatet vedlikeholdes fortsatt. [Ref]

1.2.8 7-bits systemer (128 tegn) var standard helt til langt ut på 1980-tallet. Senere kom 8-bits systemer. Men de 256 tegnene i slike systemer er langt fra nok til å representere alle tegn i de forskjellige nasjonale variantene av det latinske alfabetet. De 52 bokstavene i det engelske alfabetet ("a".."z" og "A".."Z") samt tallene ("0".."9") og de vanligste setningstegnene ligger i nedre del (de første 128) av tegnregisteret [5], som er felles for alle nasjonale varianter. Andre tegn er lagt til øvre del, som derfor finnes i så mange versjoner som trengs for å dekke de språkvariantene som finnes av datasystemene.

1.2.9 Derfor har det ofte vært vanskeligheter med å utveksle tekster på forskjellige språk mellom forskjellige datasystemer. Mange er f.eks. de som har fortvilt over at de "særnorske"; bokstavene "Æ", "Ø", "Å", "æ", "ø", og "å" kommer frem som helt andre tegn dersom en datafil sendes fra en maskin til en annen, eller fra ett program til et annet. (Slike problemer har av og til fått pussige konsekvenser — de har f.eks. fristet mer enn én nordmann til å vende tilbake til den alderdommelige skrivemåten "aa" for "å", og til den tyskinspirerte konvensjonen "ae" for "æ" og "oe" for "ø".) For alfabetiske skriftsystemer er problemer som disse plagsomme, men praktisk overkommelige. For skriftsystemer med tusenvis av tegn, som f.eks. det kinesiske eller japanske, kan begrensninger i tegnrepertoar være langt mer problematiske.

1.2.10 I de siste årene har en 16-bits tegnstandard (65.536 tegn), Unicode, fått stadig større utbredelse. Det har også vært arbeidet med planer for en 32-bits (4,3 milliarder tegn) standard. Slike standarder løser langt på vei de problemene som har vært forårsaket av datasystemenes begrensede tegnrepertoar. (16 bits har faktisk vist seg å være litt knapt, men med 32 bits skulle man ha dekket behovene for all overskuelig fremtid.) Dette er et betydelig og viktig fremskritt, men det vil ikke løse alle problemer med representasjon av tekst i elektronisk form.

1.2.11 I datasystemer er tekster representert som lineære sekvenser av diskrete tegn. Dette er hensiktsmessig, fordi datamaskiner behandler slike tegnsekvenser meget effektivt. Ikke bare kan de enkelt produseres og lagres, de kan også pålitelig og raskt manipuleres, analyseres, telles, sorteres osv. Det er nettopp derfor datamaskiner har vist seg å være slike effektive hjelpemidler i tekstbehandling.

1.2.12 De fleste vil nok kunne enes om at man ved hjelp av en slik lineær tegnstreng kan ta vare på det vesentligste i skriftlige eller muntlige verbale budskap, nemlig tegn- eller ordfølgen. Likeså lett vil man nok kunne enes om at tekster er noe mer enn slike lineære tegnsekvenser. For eksempel inneholder tekster typografiske trekk som kursiv, fete typer, spesielle skrifttyper osv. som gjerne markerer spesielle fenomener som utheving, fremmedord, egennavn, referanser o.l. Dessuten finner man ofte at disponeringen av skriftbildet på papiret, som i tabeller, dikt, o.l., er av betydning for en riktig forståelse av teksten. Videre vil man i de fleste tekster finne kryssreferanser, registre og annet som bryter den lineære ordenen. Enn videre vil man i de fleste tekster finne inndelinger i deler, kapitler, avsnitt etc. For øvrig inneholder tekst ofte også bilder, diagrammer og andre visuelle elementer som ikke uten videre kan representeres alfanumerisk. [6]

1.2.13 Det finnes ikke noe "alfabet" for gjengivelse av slike trekk. De lar seg ikke uten videre representeres direkte og behandles av datamaskiner. Det er derfor man gjerne representerer dem ved merker eller koder i form av alfanumeriske strenger som er synlige for programvare som skal behandle teksten, men vanligvis ikke for den menneskelige leseren. Dermed kan de aktuelle trekkene gjenfinnes og behandles med samme effektivitet som tekstens øvrige innhold.

1.2.14 Dette forutsetter at kodingen er konsekvent gjennomført, og at den er utformet i samsvar med regler som gjør det mulig å behandle den automatisk. Et kodesystem definerer derfor et sett av reserverte strenger og angir formelle regler for bruk av slike strenger i tekstfiler. Koding er altså en form for meta-informasjon. Koder er tegnsekvenser som sier noe om hvordan andre tegnsekvenser skal behandles. Vanligvis vil koder være spesielle, reserverte kombinasjoner av tegn som også forekommer i vanlig, direkte representerende funksjon.

1.2.15 Det har lenge vært et problem at merkingen ikke har fulgt noen standard. Hver enkelt produsent av programvare eller tekst har gjerne hatt sitt eget kodesystem. I lang tid kunne det virke som om mange programvareprodusenter betraktet kodesystemet som en strategisk faktor i kampen for å holde på kundene. Det fantes gjerne ingen offentlig tilgjengelig dokumentasjon av kodesystemene. Dermed ble det vanskelig for konkurrentene såvel som for brukerne å skaffe seg innsikt i det. Mangelen både på standarder og på dokumentasjon gjorde utveksling og gjenbruk av såvel programvare som elektroniske tekster vanskelig og ressurskrevende. [Coombs et al]

1.2.16 I de siste årene har denne trenden snudd. Programvareprodusenter viser langt større åpenhet m.h.t. kodesystemene de benytter, og tilbyr oftest funksjoner for oversettelse til og fra andre systemer. Det har vært nedlagt betydelig internasjonalt arbeid for å komme frem til felles standarder for koding av tekst. Sterke krefter innen dataindustrien selv har stått bak mye av denne utviklingen, hvis primære siktemål kan sies å være effektivisering av produksjon og distribusjon av elektronisk tekst og programvare for tekstbehandling. Ett av resultatene av dette arbeidet er Standard Generalized Markup Language (SGML).

1.3.1 Standard Generalized Markup Language (SGML) ble utviklet av dataindustrien (med IBM som en av hovedaktørene) for å løse de praktiske problemene man hadde med gjenbruk av data og programvare i forbindelse med kontorautomasjon og utgivelse i virksomheter med store dokumentasjonsbehov. SGML fikk etter hvert vid utbredelse og ble en de facto standard for deler av industrien og det offentlige byråkrati. SGML ble f.eks. tidlig benyttet såvel av selskaper som IBM og Boeing som av det amerikanske Forsvarsdepartementet, EUs administrasjon og en rekke av de aller største forlagene.[Ref, se Allen R..] I 1986 ble SGML godkjent som internasjonal standard [ISO 8879-1986]. SGML er i dag et referansepunkt for all diskusjon av tekstkoding, og vil derfor også stå i fokus for mye av fremstillingen i det følgende.

1.3.2 Strengt tatt er SGML ikke i seg selv et kodesystem, men snarere et sett av regler for hvordan kodesystemer kan utformes. Derfor er det aldri bare ett svar på hvordan et konkret dokument skal kodes i SGML. Det kan likevel være hensiktsmessig å ta utgangspunkt i et konkret eksempel, f.eks. de første linjene av Ibsens Peer Gynt [Ref]:

Fig 1.

1.3.3 Den første linjen (DOCTYPE-deklarasjonen) kan vi foreløpig se bort fra. Teksten er delt inn i elementer markert med såkalte startmerker og sluttmerker. Merker atskilles fra resten av teksten med reserverte tegn, såkalte markører. Et startmerke begynner med markøren "<" og slutter med ">", mens et sluttmerke begynner med markøren "</" og slutter med ">". [7] Hvert enkelt merke inneholder en generisk identifikator (GI) som tilordner vedkommende element til en bestemt elementtype (her text,front, title osv.). [8] Elementer inneholder ytterligere elementer, som i sin tur inneholder de aktuelle delene av "selve teksten" i vanlig alfanumerisk form. "Særnorske" bokstaver, som "å" og "Å", er erstattet av såkalte entiteter, henholdsvis "ø" og "&aring". For bedre å kunne konsentrere oss om elementstrukturen kan vi erstatte elementenes innhold med "...":

1.3.4 Dokumentets aller første linje, " <!DOCTYPE text SYSTEM "gynt.dtd"> " er dets dokumenttype-deklarasjon, også kalt DOCTYPE-deklarasjon. I dette tilfellet sier deklarasjonen at det foreliggende dokumentet er av typen text, og at det finnes en definisjon av dette elementet på filen "gynt.dtd". Denne definisjonen utgjør dermed en dokumentmal, som i SGML har form av en dokumenttype-definisjon (DTD). En DTD inneholder formelle regler for hvilke elementer et dokument kan inneholde og hvordan de kan kombineres. En DTD for ovenstående dokument kan for eksempel se slik ut:

1.3.5 Den innledende strengen "<!ELEMENT" og det avsluttende tegnet ">" i første linje indikerer at den utgjør definisjonen av en elementtype, i dette tilfellet elementtypen text. "O O" markerer at både startmerket og sluttmerket for dette elementer av denne typen under visse vilkår kan utelates. (Hva det vil si kommer vi straks tilbake til.) Uttrykket i parentes, "(front,body)" utgjør elementtypens innholds-modell. I dette tilfellet angir innholds-modellen at alle elementer av typen text må inneholde et front-element etterfulgt av et body-element.

1.3.6 Tilsvarende sier neste definisjon at front-elementer må inneholde et title-element etterfulgt av et author-element, mens de to etterfølgende definisjonene av author og title sier at disse elementene kan inneholde alfanumeriske data, men ingen andre elementer. Elementer av typen body kan inneholde ett eller flere sp-elementer. sp-elementer kan (men må ikke) inneholde et innledende stage-element. I tillegg må elementet inneholde alfanumeriske data og/eller ml-elementer i vilkårlig rekkefølge. stage har samme definisjon som author og title og kan dermed bare inneholde alfanumeriske data. Nest siste linje, definisjonen av ml, sier at dette er tomme elementer, dvs. de skal ha en startmarke men ikke noen sluttmerke.

1.3.7 Aller siste linje starter ikke med "<!ELEMENT", men med "<!ATTLIST"; den definerer nemlig en attributt. I dette tilfellet sier definisjonen at elementer av typen sp har en attributt med navnet "who", at denne attributten kan gis verdiene "A" eller "P", og at verdien "P" vil bli antatt dersom ingen annen verdi er spesifisert.

1.3.8 Dermed er alle elementer i vårt lille eksempel definert. [10]Det er mange andre dokumenter enn vårt eksempel som oppfyller disse reglene. [11] DTDen sies derfor å definere en klasse eller type av dokumenter — derav navnet dokumenttype. Et dokument som samsvarer med en DTD sies å være gyldig. At et SGML-dokument er gyldig vil altså si at det samsvarer med reglene som er angitt i dokumentets DTD. [12]

1.3.9 SGML har mange fordeler fremfor andre måter å representere tekst på. For det første er tegnsettet begrenset og kontrollert. Det betyr at dokumenter kan overføres mellom ulike datamaskiner, operativsystemer og dataprogrammer uten tap av informasjon. I vårt eksempel forekommer f.eks. de norske bokstavene "ø" og "å", som ofte blir offer for feil ved overføring mellom systemer, erstattet av entiteter som ikke vil utsettes for slike feil.

1.3.10 For det andre er dokumenters elementer eksplisitt, entydig og konsistent markert i samsvar med en veldefinert formalisme. Det betyr at man kan benytte velkjente og robuste algortimer i såkalt parsing, dvs. identifikasjon av dokumentstruktur. Dette er en av de aller mest grunnleggende operasjonene i behandling av kodede dokumenter.

1.3.11 For det tredje er det ikke dokumentets visuelle utforming (fete typer, linjeskift etc.), men dets underliggende struktur (replikker, verselinjer etc.), som er kodet. [13] Det betyr at det er relativt enkelt å gjengi teksten såvel med den opprinnelige visuelle utformingen (i fig 1) som med annen layout. Det betyr også at det er enkelt å automatisere gjenfinning av tittel, forfatternavn osv., og at en forholdsvis enkelt vil kunne gjøre slikt som å ekstrahere eller søke i bare Åses eller bare Peers replikker.

1.3.12 Tilsammen betyr dette at vesentlige hindringer for gjenbruk av data og programvare er overvunnet. SGML tillater oss å kode nesten en hvilken som helst struktur som forekommer i andre kodesystemer og tekstbehandlingsformater. SGML egner seg derfor både som primærformat og som utvekslingsformat mellom andre kodesystemer.

1.3.13 For det fjerde støtter elementstrukturen i SGML godt opp om en datastruktur som er mye brukt og har vist seg nyttig i utformingen av programmer for tekstbehandling. I stedet for bare å fremstå som en lineær sekvens av tegn, kan et SGML-dokument nemlig transformeres til en rettet graf i form av et såkalt dokumenttre. Visuelt kan treet for vårt lille eksempel fremstilles slik:
Fig. 5

1.3.14 I likhet med lingvistenes syntaks-trær tegnes dokumenttrær med roten i været. Det øverste elementet, text, kalles derfor roten, eller rot-elementet. Grafen kan leses ovenfra og ned ved å følge linjene fra høyereliggende til lavereliggende elementer, og fra venstre mot høyre ved å følge linjene mot venstre før de mot høyre. Dermed kan vi lett se at rot-elementet inneholder elementene front og body, at front-elementet kommer før body, at body inneholder fem sp-elementer osv. Vi kan også lese grafen motsatt vei og med et blikk konstatere at "Hvorfor banne?" er en av Peers replikker, at den er fjerde replikk i stykket, og at replikken inngår i body som er inneholdt direkte av rot-elementet.

1.3.15 Datastrukturen har minst like store fordeler for utformingen av dataprogrammer som for visualisering. Uten en slik datastruktur vil operasjoner som f.eks. å finne fjerde replikk, å finne ut hvilke elementer den inneholdes av, å ekstrahere alle Peers replikker osv. gjerne forutsette at programmet skanner dokumentet fra begynnelsen av til det finner frem til de elementene som tilfredsstiller betingelsene. Dersom dokumentet er representert i samsvar med tre-strukturen ovenfor vil slike oppgaver være betydelig lettere da man med en slik representasjon kan identifisere de aktuelle elementene med noen ganske få operasjoner.

1.3.16 For det femte utgjør SGMLs DTDer et kraftig redskap i utøvelse av kontroll over dokumentstruktur. En DTD er en formalisert spesifikasjon av hvilke elementer et dokument kan inneholde og hvordan de kan kombineres. Også denne spesifikasjonen er utformet i samsvar med en veldefinert formell grammatikk som det finnes velkjente og robuste algoritmer for å behandle. Det betyr at det er mulig å sjekke automatisk om et gitt dokument er gyldig — dvs. om det samsvarer med de reglene som er uttrykt i dets DTD. I følge vår DTD vil det for eksempel ikke være lov å ha scenehenvisninger (stage-elementer) noe annet sted enn i begynnelsen av replikker (sp-elementer). En slik feil ville umiddelbart oppspores av en såkalt validerende parser.

1.3.17 Det å kunne utøve slik kontroll over dokumentstruktur kan være nyttig i mange sammenhenger. Arbeider man med en diktsamling, kan man for eksempel spesifisere at en tekst av typen "diktsamling" skal inneholde ett eller flere dikt, at hvert dikt skal ha en tittel og inneholde ett eller flere vers, at hvert vers skal inneholde en eller flere verselinjer osv. I en annen DTD kan man spesifisere at en rapport skal begynne med dato, tittel, forfatter og sammendrag, og deretter bestå av ett eller flere kapitler osv. Dermed kan man oppnå god kontroll med dokumenters struktur — vi kan f.eks. få hjelp av SGML-programvare til å forsikre oss om at at alle dikt har vers som inneholder verselinjer, at alle rapporter inneholder sammendrag, osv.

1.3.18 For det sjette er SGML et meget fleksibelt system. I stedet for å angi hvilke fenomener som skal kodes eller nøyaktig hvordan de skal kodes, begrenser SGML seg til å spesifisere en syntaks for utforming av kodesystemer. Stilt overfor et gitt fenomen er det helt og holdent opp til brukerne i hvert enkelt tilfelle å bestemme om og evt. hvordan fenomenet skal kodes. Skal vi f.eks. gjengi en tekst der navnet "Kari Hansen" er trykt i kursiv, er det ingenting i SGML som tvinger oss til å kode det. Skal det kodes, kan det gjøres på utallige måter, f.eks.: [14]

1.3.19 SGML er altså et meget kraftig og fleksibelt representasjonssystem som byr på betydelige fordeler, sammenlignet med mange andre måter å representere tekst på. De mest grunnleggende mekanismene i SGML er dessuten så enkle at de er forholdsvis lette å tilegne seg. En del brukere og kommentatorer har likevel beklaget seg over at SGML har en rekke kompliserende faktorer og begrensninger som gjør at SGML trass i disse fordelene ikke er så godt egnet som et generelt system for representasjon av tekst helst bør være. I vår sammenheng er det særlig én slik komplikasjon og én begrensning som er av interesse.

1.3.20 En av de kompliserende faktorene er at et SGML-dokument oftest ikke kan parses uten tilgang til dets dokumentmal (DTD). [15] Det skyldes blant annet at et tomt element syntaktisk ikke skiller seg fra et startmerke. En SGML-parser vil typisk lese en SGML-fil tegn for tegn fra begynnelse til slutt mens den bygger opp en representasjon av dokumentets struktur, gjerne i form av et dokument-tre. Når den leser (fig 2 og 3) ovenfor, vil en parser som ikke har adgang til dokumentets DTD ved møtet med den første forekomsten av merket " <ml> " måtte forvente å støte på et tilsvarende sluttmerke senere. Det er først når den møter sluttmerket " </sp> " parseren kan konkludere at " <ml> " må ha markert et tomt element. Dette er ikke bare et problem for parsere — også menneskelige lesere kan lett få problemer med å holde rede på hvilke elementer som er tomme og ikke i et litt komplisert SGML-dokument.

1.3.21 Problemet blir forsterket av SGMLs muligheter for forenkling av merkingen ved bruk av tomme merker eller utelatelse av merker. I en litt komplisert tekst blir kodingen lett av et omfang som nærmer seg eller endog overgår omfanget av "selve teksten". Derfor tillater SGML at noe av kodingen forenkles. Informasjonen om hvilket element som avsluttes av hvert enkelt sluttmerke er f.eks. egentlig unødvendig, ettersom den stort sett fremgår direkte av dokumentets struktur for øvrig. Derfor tillater SGML bruk av tomme sluttmerker, dvs. at sluttmerkets GI kan utelukkes. Vårt eksempel kan f.eks. forenkles på følgende måte:

1.3.22 Slik reduksjon av kodingen kan nok i mange tilfelle gjøre dokumentstrukturen enklere å identifisere for den menneskelige leser — for en parser gjør det imidlertid oppgaven vanskeligere. Når en parser etter å ha lest den første forekomsten av " <ml> " i (fig 6) støter på et tomt sluttmerke (" </> ") er det ikke uten videre mulig å avgjøre om det er ml-elementet som avsluttes og et annet element som er tomt, eller omvendt. Faktisk er kodingen (i fig 6) konsistent med en antagelse om at det ikke er ml-elementene, men sp-elementene, som er tomme. [16]

1.3.23 SGML tillater imidlertid ytterligere forenkling av kodingen. Jeg nevnte at "O O" i DTDen ovenfor markerer at både startmerket og sluttmerket for dette elementet under visse vilkår kan utelates. Vilkåret er at et det er mulig å identifisere dokumentstrukturen korrekt på grunnlag av dokumentet og DTDen samlet. Under denne forutsetningen kan vi utelate en god del av merkene i ovenstående eksempel og f.eks. ende opp med følgende:

1.3.24 Muligheten til å redusere eller utelate koding er utvilsomt fordelaktig i visse sammehenger. Når man først kjenner systemet, kan det f.eks. være lettere å legge inn koder manuelt i samsvar med fig 7 enn i samsvar med (fig 2 og 3). Denne mulige fordelen er imidlertid oppnådd mot store kostnader. Mens det uten slik reduksjon ikke er helt problemfritt å parse dokumenter uten tilgang til deres DTD, er det med benyttelse av slike muligheter blitt helt umulig. Siden det i mange sammenhenger der man kan ta dokumenters gyldighet for gitt i og for seg er unødvendig å parse DTDen, ville det derfor være en betydelig forenkling å kunne parse dokumentstrukturen direkte, uten å støtte seg på en DTD. [17]

1.3.25 SGML som sådan legger ingen restriksjoner på hvilke eller hvor mange elementer vi kan ha i et dokument av en bestemt type eller på hvilke elementer som kan inneholde hvilke andre. Derimot legger SGML en viktig begrensning på dokumenters struktur: Alle elementer må være hierarkisk ordnet. Elementer inneholder ett eller flere elementer, som igjen kan inneholde elementer. Dette betyr at det er en del mer komplekse strukturer, f.eks. overlappende elementer, som ikke kan representeres direkte i SGML. [18]

1.3.26 I vårt lille Peer Gynt-eksempel finnes slik overlapp i form av overlapping mellom replikker og metriske linjer (verselinjer). Det er nettopp derfor metriske linjer i eksemplet er markert med tomme ml-elementer, dvs. som " <ml> ". Dersom vi valgte å kode metriske linjer som "vanlige" innholdselementer, kunne vi f.eks. tenke oss at det ble gjort slik:

1.3.27 Det kan derfor med all rett hevdes at overlappende strukturer faktisk kan representeres i SGML — omenn på en noe indirekte måte. På den annen side kan det innvendes at nettopp det at overlappende strukturer representeres på en slik indirekte måte medfører ulemper. En av ulempene er at en SGML-parser ikke vil kunne oppfatte " <ml> " som annet enn markering av punkter i dokumentet. I vårt tilfelle vil et SGML-basert gjenfinningsprogram f.eks. kunne ekstrahere alle replikker som inneholder bestemte ord, men ikke de metriske linjene som inneholder disse ordene. Det er selvfølgelig mulig å skrive eller modifisere programvare som kan håndtere slik bruk av tomme elementer på den måten som er tilsiktet, men det er altså ikke del av SGML-standarden. [20]

1.4.1 Helt spesiell betydning for utbredelsen av SGML fikk World Wide Webs suksess og eksplosive vekst på 90-tallet. Dokumentstandarden som benyttes på Web, kjent under navnet HTML (HyperText Markup Language), er nemlig basert på SGML. Webs voldsomme popularitet kan dermed sies å representere en suksess også for SGML.

1.4.2 Som tidligere nevnt er SGML strengt tatt ikke selv et kodesystem, men et sett av regler for utforming av kodesystemer. HTML er et slikt kodesystem, utformet i samsvar med SGMLs regler. Det betyr at HTML inneholder et repertoar av definerte koder som sier oss hva vi bør (eller kan) kode, og regler for hvor i et dokument disse kodene kan forekomme. HTML gjør bare bruk av en liten del av SGMLs syntaktiske strukturer, og inneholder et forholdsvis lite antall koder med relativt enkle kombinasjonsregler.

1.4.3 HTMLs grunnstruktur er derfor også meget enkel: et HTML-dokument utgjør et HTML-element som består av et HEAD-element etterfulgt av et BODY-element. HEAD-elementet inneholder referanseinformasjon (dokumentets tittel, stikkord, evt. opplysninger om forfatter, tegnsett osv.) mens BODY-elementet inneholder "selve dokumentet" (tekst delt inn i overskrifter, avsnitt, tabeller etc.). Kodet i HTML kan vårt eksempel f.eks. se slik ut:

1.4.4 Som vanlig er for SGML-dokumenter, starter også dette med en doctype-deklarasjon. Av denne fremgår det at den DTD som brukes har et offisielt navn, nemlig "-//W3C//DTD HTML 4.0//EN", og at den kan finnes på adressen "http://www.w3.org/TR/REC-html40/strict.dtd". [21] I HEAD-elementet angir det tomme META-elementet dokumentets forfatter, og TITLE-elementet inneholder dets tittel. BODY-elementet inneholder ett eneste P-element (P for "paragraph", "avsnitt"), som i sin tur inneholder selve teksten med rolleangivelser markert som B-elementer (B for "bold", "fet skrift") og linjeskift markert som tomme BR-elementer (BR for "break", "linjeskift").

1.4.5 Eksemplet kan tjene til å illustrere HTMLs styrke: Kodingen vil nemlig gi nærmest nøyaktig samme visuelle resultat som (fig 1) i en hvilken som helst nettleser, brukt på en hvilken som helst maskin hvor som helst i verden. For det første har man gjennom bruk av SGML sikret seg at selve det kodede dokumentet kan overføres uten feil eller informasjonstap. For det andre finnes det vel etablerte de facto standarder for hvordan de fleste HTML-koder skal vises på skjerm og papir. Når det i tillegg også er slik at de fleste koder har et umiddelbart synlig resultat, er HTML med sin enkle struktur og forholdsvis begrensede repertoar av koder også meget enkelt både å lære og å bruke. HTML er i dag brukt på nær sagt alle typer tekst — det aller meste av den enorme tekstmassen som allerede nå befinner seg på Web er som nevnt kodet i HTML. Dette kan tyde på at HTMLs begrensede kodesett i det minste dekker de mest sentrale behovene for koding av mange typer tekst.

1.4.6 Noe man kan merke seg med denne typen koding er at den inneholder en blanding av koder som beskriver elementers funksjon eller innhold (f.eks. HEAD, BODY, META og TITLE), og koder som utelukkende beskriver elementenes visuelle egenskaper (f.eks. B og BR). [22] Vi kan foreløpig kalle dette henholdsvis innholdsorientert og utseendeorientert koding. Vi kan videre merke oss at en god del av den innholdsorienterte kodingen vi brukte i SGML-eksemplet (fig 2-9) er utelatt eller erstattet med utseendeorientert koding i HTML-eksemplet. Det er f.eks. ingen markering av replikker, rolleangivelsene er bare markert som fet skrift, og det er ikke metriske linjer, men visuelle linjeskift som er markert.

1.4.7 HTML har da også i stor grad vært orientert mot dokumenters utseende snarere enn mot strukturerering av deres innhold. Riktignok har man innholdsorienterte elementer av typen "overskrift", "utheving" osv. som i mange tilfelle kunne erstatte utseendeorienterte elementer som "fet skrift", "kursiv", o.l. Men dessverre er det mange brukere som ikke skjelner mellom dem, eller som "misbruker" koder for å oppnå en bestemt visuell effekt. Konsekvensene er at innholdsorienterte og utseendeorienterte koder brukes om hverandre, og at HTML-dokumenter inneholder en god del feil koding.

1.4.8 At HTML-koder ofte "misbrukes" for å oppnå bestemte visuelle effekter skyldes nok dels at nettleserne binder hver enkelt kode til en bestemt visuell utforming, dels at brukerne hverken kan legge til nye elementer eller modifisere definisjonen av eksisterende elementer i HTML. Det er gjort mye for å rette på det første — bl.a. er det innført en type stilark (såkalte Cascading StyleSheet (CSS)) som gjør det mulig å binde elementer til alternative typografiske utforminger. På den måten er det f.eks. mulig å presentere samme dokument med forskjellige stilark tilpasset forskjellige sammenhenger. [23]

1.4.9 Det er bare få av de redskapene som til nå har vært mest brukt for tilrettelegging av HTML-dokumenter som sjekker om kodingen av dokumentene stemmer med den DTDen som gjelder for den aktuelle versjonen av HTML. De eneste feilene brukerne ledes til å rette, er dermed de som gir seg synlige utslag. Av samme grunn vil kodinger som gir samme synlige resultat lett kunne blandes, selv om de er prinsipielt forskjellige.

1.4.10 Kodefeil kan gi uforutsigelige resultater. Det er muligens på grunn av innbyrdes konkurranse programvareprodusenter likevel har funnet det bedre å gi brukeren et halvgodt dokument enn en feilmelding. Følgende er for eksempel opplagt ugyldig:

1.4.11 Når programvare for tilrettelegging av HTML-dokumenter tolererer kodefeil, er det kanskje ikke overraskende at også nettlesere tolererer slike feil. En paradoksal konsekvens av denne robuste toleransen for feil er at World Wide Web sannsynligvis inneholder verdens største samling av ugyldige SGML-dokumenter. En annen paradoksal konsekvens er at produsentene av nettlesere i sin innbyrdes konkurranse stadig har føyet nye elementer til HTML, slik at det til enhver tid har eksistert forskjellige "dialekter" av kodesystemet. Dette har i sin tur ført til at dokumenter som bruker disse kodene periodevis har vært "bundet" til bruk av bestemte versjoner av de forskjellige nettleserne. [24] Med andre ord har vi endt opp med en situasjon som er nærmest den motsatte av det som var intensjonen med SGML. I stedet for standardisering, er resultatet blitt et mangfold av innbyrdes mer eller mindre forenlige kodesystemer. [25]

1.4.12 Med dagens nettlesere kan man stort sett bare vise HTML-dokumenter. Det betyr at SGML-dokumenter som er tilrettelagt med en annen DTD enn HTML, må "oversettes" til HTML før de kan legges på Web. [26] Mye av den informasjonen som legges inn i tekster basert på mer avanserte SGML-systemer kan derfor gå tapt når de oversettes til HTML for publisering på Web. Siden Web er vår tids viktigste distribusjonskanal for elektronisk tekst er dette en betydelig ulempe.

1.4.13 Selv om HTML er en SGML-basert standard, har det altså en del eiendommelige trekk som strider mot mange av de grunnleggende tankene bak SGML: For det første kan brukerne ikke endre DTDen, og HTML er dermed grunnleggende statisk. For det andre er HTML i stor grad utseendeorientert, snarere enn innholdsorientert. For det tredje utnyttes muligheten for automatisk validering bare i liten grad.

1.5.1 Som nevnt (i 1.2) har mangelen på standarder for representasjon av elektronisk tekst lenge skapt problemer med utveksling og gjenbruk av tekster såvel som programvare for tekstbehandling. Dette har medført store omkostninger for edb-brukere generelt, men det har kanskje vært et spesielt alvorlig problem for humaniora. Mens andre disipliner kan sies å benytte tekster primært som et redskap til formidling av informasjon om et forskningsobjekt, er det ofte teksten som er selve forskningsobjektet for humanisten. Mens tekster i andre sammenhenger har et relativt kort historisk liv, arbeider humanister ofte med tekster som overleveres gjennom hundreder og tusener år. Dessuten kan alle tekster sies å være potensielle objekter for historiske studier av ulike slag en gang i fremtiden. Humanistisk forsking har derfor en interesse ikke bare i å lette utveksling og gjenbruk av de tekstene som forskningen selv produserer eller benytter i dag. Man er også opptatt av at tekst som er produsert i helt andre sammenhenger skal kunne tas vare på i en form som gjør det mulig å bruke dem også i fremtidig forskning.

1.5.2 Dessuten er humanistisk forskning ofte avhengig av spesialprogramvare som i praksis må utvikles av de humanistiske forskningsmiljøene selv. I tillegg til kostnadene ved å utvikle slik programvare kommer kostnadene ved å vedlikeholde den og sørge for at den kan brukes på tekster lagret i forskjellige og vekslende formater. Humanistiske forskere og institusjoner med ansvar for kildebevaring, som arkiver og biblioteker, viste derfor tidlig interesse for standardisering av formater for tekstrepresentasjon.

1.5.3 Allerede i 1987, bare ett år etter at SGML var etablert som ISO-standard, tok arbeidet med Text Encoding Initiative til. I 1994 forelå TEIs Guidelines for Electronic Text Encoding and Interchange, resultat av et samarbeid mellom et hundretalls forskere fra alle humanistiske disipliner. [27] TEI Guidelines beskriver et av de mest omfattende og avanserte tekstkodesystemer som noen gang er laget.

1.5.4 Systemet er basert på SGML. Det består av en rekke DTD-moduler [28] som kan settes sammen og tilpasses etter behov. Det finnes én modul, kjernemodulen, som må inngå i ethvert TEI-system. Man må også velge seg en (og normalt bare én) blant flere alternative "base"-moduler. Hver base kan så kombineres fritt med en eller flere av en rekke forskjellige tilleggsmoduler.

1.5.5 I kjernemodulen defineres tekstelementer som antas å forekomme i de fleste typer tekst, og som elementer i de andre modulene bygger på. Det finnes fire forskjellige base-moduler: én for prosa, poesi og drama, én for talespråk, én for ordbøker og én for terminologi. I tillegg til disse kan man så velge fritt blant tilleggsmoduler for f.eks. lingvistisk analyse, tekstkritisk apparat, lenking osv.

1.5.6 For mange fenomener tilbyr TEI ikke bare én representasjonsmåte, men et knippe av alternative muligheter. TEI Guidelines diskuterer fordeler og ulemper ved de ulike alternativene, og oppfordrer brukeren til selv å vurdere hvilket forslag som er det beste i hans spesielle tilfelle.

1.5.7 TEIs ambisjonsnivå er ikke beskjedent. Det har faktisk vært prosjektets eksplisitte målsetting å

1.5.8 TEI er altså en omfattende, men også en liberal standard. Den omfatter et stort antall teksttyper og et rikt mangfold av tekstlige fenomener, den er modulært oppbygget, og den er modifiserbar. TEI har fått bred anvendelse innen humaniora og brukes også utenfor den rent akademiske verden. Siden utviklingsprosjektet ble avsluttet i 1994 er det bygget opp et stort og aktivt brukerfellesskap som ble formalisert gjennom etableringen av TEI Consortium; i 2000. Det arbeides kontinuerlig med videre utvikling av systemet.

1.5.9 Man kan med fordel skille mellom TEI Guidelines og det konkrete settet av DTD-fragmenter som er utarbeidet av TEI. Mens Guidelines angir en generell anbefaling av hvordan tekst bør kodes, utgjør DTD-modulene en teknisk implementasjon av disse anbefalingene. Man kan dermed si at mens Guidelines i prinsippet ikke er bundet til SGML, leverer TEI også hjelpemidler som setter en i stand til å følge disse anbefalingene ved bruk av SGML. Som vi tidligere (i 1.3) har sett, inneholder SGML en del kompliserende fakturer og begrensninger. En god del av Guidelines er derfor viet diskusjon av disse begrensningene, og tilbyr et rikt utvalg av mekanismer for å omgå dem. Blant tekstlige strukturer som ikke lett kan representeres i SGML er overlappende og diskontinuerlige elementer. TEI Guidelines diskuterer disse problemene eksplisitt, og byr på et antall mekanismer som kan benyttes for å håndtere f.eks. overlappende elementer i SGML.[Se Sperberg-McQueen og Huitfeldt ... samt ... for en oversikt over disse.]

1.5.10 En følge av modulariteten, modifiserbarheten, de tallrike alternative måtene å behandle samme fenomener på og de mange mekanismene for å hanskes med fenomener som er vanskelige å representere i SGML, er at TEI kan synes unødig komplisert og uoversiktlig for bruk i sammenhenger der behovene er enkle og vanskelighetene få. Derfor er det også utarbeidet en "lett" versjon av TEI, TEILite. TEILite er hverken modulær eller modifiserbar, og inneholder få alternative eller "avansert"e mekanismer. TEILite er blitt vel så populær som "originalen".

1.5.11 Et gjennomgående trekk ved TEI Guidelines er skillet mellom representasjon og interpretasjon. Til å begynne med var TEI organisert i fire arbeidsgrupper. én av dem var gruppen for "text representation", en annen var gruppen for "text analysis and interpretation". Den første skulle ta seg av "representation of those characteristics of texts represented or signalled by conventional typography". Den andre skulle ta seg av "encoding of the results of text analysis." [TEI P1 s iv.] Det kan altså se ut til at man forestilte seg at skillet mellom representasjon og interpretasjon var relativt klart og uproblematisk. Under arbeidets gang ble det pekt på at det som her så ut til å oppfattes som "objektive" fakta, nemlig fenomener som signaliseres gjennom typografi o.l., i praksis ofte viser seg å være resultater av fortolkning og analyse.

1.5.12 Den endelige utgaven av TEI Guidelines uttrykker en mer pragmatisk holdning til skillet mellom representasjon og interpretasjon[TEI P3 s 6], men ender opp i en uavklart posisjon. Fremdeles legges det gjennomgående vekt på å gi brukeren redskaper til å skille mellom representasjon og interpretasjon. Likevel defineres "markup" som "any means of making explicit an interpretation of a text." [TEI P3, s 13] Interpretasjon beskrives som "information added to the text in addition to the transcription, " [TEI P3 p 1025] — ja, til og med som "information which is felt to be non-obvious, contentious, or subject to disagreement." [TEI P3 p 113] For den som ønsker å bruke TEI til å representere et kildemateriale så nøyaktig, pålitelig, nøytralt og fortolkningsfritt som mulig er det rimeligvis ikke særlig oppløftende å høre at tekstkoding er lutter subjektiv fortolkning.

1.5.13 TEI Guidelines er altså ikke helt fri for problemer. Likevel må prosjektets sterke ytelser fremheves. Det står fast at humanistiske forskere i et omfattende internasjonalt samarbeid her har utarbeidet et av de mest avanserte tekstkodesystemer som finnes. Det står også fast at dette systemet har funnet bred anvendelse og har blitt akseptert også ut over humanistiske eller akademiske miljøer. Fremfor alt har TEI vist seg som et fruktbart og rikt forum for debatt. [29] De problemene TEI Guidelines har synliggjort er både interessante og viktige. Tidligere upåaktet fellesgods mellom vidt atskilte teksttyper og virksomheter har kommet til syne.

1.6.1 De tidligere (i 1.4) omtalte ulempene ved HTML førte til at mange, blant annet i akademiske miljøer, så seg om etter muligheter til å overføre andre SGML-dokumenter enn bare HTML via Web. Programvare egnet til dette formålet kom på markedet ganske tidlig. Allerede midt på 90-tallet lanserte det svenske firmaet Synex sin nettleser, senere kjent bl.a. under navnet Panorama. Panorama leste både vanlig HTML og andre SGML-dokumenter, validerte dokumentene og tillot brukeren å knytte forskjellige stylesheets til dem.

1.6.2 Synex' teknologi ble integrert i en rekke produkter og fikk betydelig utbredelse. Likevel fortsatte HTML og de adskillig mindre avanserte HTML-leserne å dominere. Årsakene til dette var nok sammensatte. Det er grunn til å anta at én av årsakene rett og slett var SGMLs kompleksitet. At SGML tillater så mange former for "forenkling" av kodingen og så mange alternative mekanismer gjør som nevnt programvareutvikling for SGML krevende. I dette ligger nok også mye av grunnen til HTMLs popularitet — selv om HTML kutter mange hjørner, imøtekommer systemet tross alt mange behov.

1.6.3 Det var på denne bakgrunnen arbeidet med XML startet: Man ønsket å kombinere HTMLs enkelhet med SGMLs uttrykkskraft og fleksibilitet. I annonseringen av den første offisielle versjonen av XML 10. februar 1998 kan man lese:

1.6.6 Det er viktig å merke seg at XML er et "subsett" av SGML, noe som betyr at alle XML-dokumenter faktisk også er SGML-dokumenter. [32] Modifikasjonene er imidlertid konsekvensrike. At tomme elementer er syntaktisk distinkte og at forenklet merking ikke er lovlig betyr ikke bare at menneskelig lesning av kodede dokumenter blir lettere. Det betyr fremfor alt at det blir mulig å identifisere dokumentstrukturen entydig uten tilgang til dokumentets DTD. Dermed er en vesentlig komplikasjon ved SGML fjernet.

1.6.7 For XML er det nemlig mulig å definere et begrep om velformethet som ikke kan anvendes på SGML for øvrig. Et SGML-dokument er enten gyldig eller ugyldig. Det er gyldig hvis og bare hvis det respekterer reglene som er formulert i dets DTD. Som tidligere nevnt (i 1.3) er det ikke generelt mulig hverken å parse eller validere et SGML-dokument uten adgang til dets DTD. Med velformethet menes i XML grovt sagt at alle startmerker i et dokument er etterfulgt av tilsvarende sluttmerker, og at alle elementer er hierarkisk ordnet. Slik XML er definert, er det mulig både å parse et dokument og å avgjøre om det er velformet, uten å sammenligne det med dets DTD. Man kan validere et dokument mot en DTD også i XML; XML skiller seg bare fra SGML ved at en DTD ikke er nødvendig — man kan nøye seg med å sjekke om det er velformet. Dette er en viktig forenkling. Mange av de prosesser et dokument gjennomgår etter at det først er tilrettelagt krever ikke gyldighet, bare velformethet. Å validere et SGML-dokument kan være relativt krevende, mens det å sjekke at et XML-dokument er velformet er meget enkelt.

1.6.8 Også XMLs suksess har vært formidabel, omenn av en annen art enn HTMLs. I tilknytning til XML ble det etablert en XML-basert standard for stilark, XSL. Med XSL ble det mulig å konvertere XML-dokumenter til HTML for publisering på Web. Det er dermed blitt vanlig å tilrettelegge og utveksle dokumenter i XML, mens XSL brukes til å generere HTML for visuell presentasjon av dokumentene på Web. Stadig mer Web-innhold bruker dermed HTML utelukkende som presentasjonsformat, med XML som primærformat. Mange SGML- eller HTML-baserte data og applikasjoner har migrert eller er i ferd med å migrere til XML. Som et eksempel kan nevnes at mens TEI P3 fra 1994 var et SGML-basert kodesystem, er TEI P4 en lett revidert XML-basert versjon av det samme systemet. [33]

1.6.9 I lys av den kritikken som har vært fremmet såvel mot SGML generelt som mot HTML spesielt, er det klart at XML betyr et betydelig skritt fremover. Fremdeles har vi imidlertid å gjøre med et kodesystem som har de samme begrensningene som SGML for øvrig, f.eks. m.h.t. representasjon av overlappende eller diskontinuerlige elementer. [34]

1.7.1 Selv om proprietære formater som f.eks. PostScript, PDF og RTF fremdeles er mye brukt, vinner XML stadig økende terreng. Kanskje er XML det mest utbredte formatet for koding og utveksling av tekst allerede i dag — og om ikke ennå, vil det sannsynligvis bli det om ikke lenge. Noe av det som gjør XML så attraktivt i mange sammenhenger er dets enkelhet. Samtidig har det vokst frem et stort og potensielt forvirrende mangfold av standarder, teknologier, anvendelser og redskaper som dels er basert på, dels utvider anvendelsesområdet eller funksjonaliteten til XML. Her er det bare plass til å nevne et utvalg av disse.

1.7.2 XSL (Extensible Stylesheet Language)[...] er en spesifikasjon som primært brukes for transformasjon av XML-dokumenter til andre former av XML, eller evt. til formater som ikke er basert på XML (f.eks. HTML eller PDF). XSL bruker XSLT (XSL Transformations) for å transformere dokumenter, XPath (XML Path Language) for å adressere steder i eller deler av dokumenter, og XSL-FO (XSL Formatting Objects) for å spesifisere formattering.

1.7.3 XLink (XML Linking Language)[...] tilbyr mekanismer for å opprette og beskrive lenker i XML-dokumenter. Med XLink kan man lage samme slags enkle lenker som i HTML, eller mer avanserte hyperlenker. XPointer er en utvidelse av XPath som bl.a. kan bruke XPointer for å spesifisere posisjonen til lenkers endepunkter. XForms,[...] er en spesifikasjon som tilfører XML funksjonalitet kjent fra HTMLs form-element. XForms er imidlertid betydelig kraftigere, idet den bl.a. har sterk data-typing og skiller dataprosessering fra presentasjon.

1.7.4 XML definerer dokumenters elementstruktur, men har bare meget begrensede midler til å kontrollere innhold, dvs. elementers innhold og attributters verdier. W3C XML Schema[...] gjør det mulig å definere XML-elementer med komplekse data-typer, i likhet med slike som finnes i høynivå programmeringsspråk. Lignende og mye brukte skjema-språk er Relax NG og Schematron. Forskjellige XML-baserte kodesystemer opererer ofte med forskjellige element-typer regler for semantisk ekvivalente strukturer. ISO HyTime-spesifikasjonen Architectural forms [...] gjør det mulig å definere DTD-moduler som kan gjenbrukes i andre DTDer, og å definere synonymi-relasjoner mellom elementer. Det er også et behov for å behandle XML-dokumenter med programmer skrevet i andre språk enn XSL SAX (Simple API for XML) og W3C’s DOM (Document Object Model)[...] tilfredsstiller dette behovet ved hjelp av en API (Application Program Interface) til XML-data.

1.7.5 XML brukes i dag ikke bare til representasjon av tekst, men også til utveksling av databasedata. XQuery[...] utgjør et søkespråk for XML som ligner på slike som er kjent fra relasjonelle databasesystemer. XQuery er delvis basert på XPath, men tilbyr ekstra funksjonalitet slik som bygging av nye XML-elementer, alternativ ordning eller utelatelse av data, datatyping osv. Andre områder der XML benyttes er grafikk og multimedia. SVG (Scalable Vector Graphics) er et XML-basert språk for generering av vektorgrafikk i visuelle presentasjoner. Et annet XML-basert språk, SMIL (Synchronized Multimedia Integration Language)[...] brukes til "streaming multimedia"-presentasjoner med tekst, lyd og levende bilder.

1.7.6 Semantiske nett (Semantic Web) [...] refererer til en rekke XML-baserte forsknings- og standardiseringsprosjekter i krysningspunktet mellom koding og kunnskapsrepresentasjon. Ett av disse tiltakene er W3Cs Resource Description Framework (RDF)[...], et annet er såkalte emnekart, spesifisert i ISO Topic Maps[...].

1.8.1 MECS (multielement System) ble utviklet for Wittgensteinarkivet ved Universitetet i Bergen på begynnelsen av 1990-tallet. MECS har mange likhetspunkter med SGML, men skiller seg fra SGML på måter som er interessante i vår sammenheng. I likhet med SGML er MECS ikke selv et kodesystem, men består av et sett av regler for spesifikasjon av kodesystemer. MECS kan altså, som SGML, sies å være et meta-språk for definering av kodesystemer. [35]

1.8.2 MECS opererer med syv grunnleggende syntaktiske strukturer. Av disse er fire relevante for fremstillingen i det følgende:

1.8.3 Tomme elementer brukes typisk til å markere punkter i en tekst, mens innholdselementer markerer områder. [36] Flerelementer brukes typisk til å markere tekstdeler som står i et bestemt forhold til hverandre, som f.eks. alternative lesemåter. [37]Entiteter brukes typisk til å representere tegn eller tegnstrenger, f.eks. "ikke-standard" tegn. [38]

1.8.4 Kodet i MECS kunne vårt Peer Gynt-eksempel (jfr. fig 1 og 2) f.eks. se slik ut:

1.8.5 Bortsett fra at markørene er endret, er elementene text, front, body, stage og ml brukt nøyaktig som i SGML-eksemplet. sp-elementene derimot, er erstattet av flerelementer med samme GI. For å lette sammenligningen med (fig 3) kan vi nok en gang erstatte elementenes innhold med "...":

1.8.6 Den aller første linjen (i fig 12 og 13), MECS-deklarasjonen, deklarerer dokumentets markører. [39] Et av de viktigste prinsippene i MECS er at alle grunnleggende syntaktiske distinksjoner er markert eksplisitt i selve kodingen av dokumentet. Et dokument som innledes med en slik angivelse av hvilke markører som er brukt kan derfor parses uten tillegg av ytterligere informasjon. Dette har gjort det mulig å gjennomføre et konsekvent skille mellom grunnleggende syntaks og øvrige egenskaper ved MECS-dokumenter. [40]

1.8.7 Det er også mulig å sjekke kodingen av et MECS-dokument mot en dokumentmal, som i MECS har form av en kodedeklarasjonstabell (CDT). En CDT (for fig 12 og 13) kan f.eks. se slik ut:

1.8.8 En CDT fastlegger altså hvordan elementer skal merkes, hvilke tegn som kan brukes i forskjellige posisjoner, og hvilke generiske identifikatorer som kan benyttes for elementer av forskjellige kategorier. En CDT kan derimot ikke uttrykke mer spesifikke regler om hvordan elementer skal eller kan kombineres i et dokument. En CDT kan f.eks. uttrykke at front, author og title er lovlige generiske identifikatorer, men ikke at front-elementer bare kan forekomme som første element i text-elementer, eller at front-elementer skal inneholde et title-element etterfulgt av et author-element.

1.8.9 Dersom et MECS-dokument inneholder en innledende MECS-deklarasjon, er det mulig å generere en CDT for dokumentet automatisk. Til enhver CDT svarer uendelig mange dokumenter, og ethvert dokument svarer til uendelig mange CDTer. Det er imidlertid én og bare én CDT som kan genereres automatisk fra et dokument. Dette er dokumentets minimale CDT. [41]

1.8.10 Om ønskelig er det mulig å forenkle kodingen. Vårt eksempel (fig 13) vil ved maksimal utnyttelse av denne muligheten se slik ut:

1.8.11 Et særegent trekk ved MECS er at systemet tillater overlappende strukturer. Følgende struktur er f.eks. lovlig i MECS:

1.8.12 MECS har altså en del trekk som skiller det fra SGML. Det klare skillet mellom grunnleggende syntaks og andre syntaktiske egenskaper finner vi riktignok også i XML. Tillatelsen av overlappende strukturer er derimot særegent for MECS, og skiller systemet både fra XML og alle andre SGML-baserte systemer. MECS ble brukt av Wittgensteinarkivet i årene 1990-1999 i tilretteggingen av Wittgensteins Nachlass, et manuskriptmateriale på ca 20.000 sider. Det ble i den forbindelse utviklet programvare for MECS som i funksjonalitet var på høyde med samtidig SGML-progrmavare. [42] Systemet har imidlertid ikke blitt brukt i særlig utstrekning utenfor Wittgensteinarkivet.

1.9.1 Som tidligere nevnt er SGML strengt tatt ikke et kodesystem i den betydningen ordet er brukt her. Det sies av og til at SGML er en grammatikk for kodesystemer. Heller ikke dette er særlig presist eller treffende. Men hvis vi med en grammatikk mener et sett av tegn og regler for kombinasjon av tegn til velformede uttrykk, kan vi kanskje si at SGML er en formell metagrammatikk — et sett av regler for definisjon av tegn og regler for formulering av regler for kombinasjon av tegn.

1.9.2 XML er som tidligere nevnt et "subset" av SGML. Derfor er heller ikke XML som sådan strengt tatt et kodesystem, men i likhet med SGML en formell metagrammatikk. At XML er et "subset" av SGML betyr grovt sagt at alt som er lovlig i XML er lovlig i SGML, men ikke omvendt. Alle XML-baserte kodesystemer er altså i samsvar med SGML, men ikke alle SGML-baserte systemer er i samsvar med XML.

1.9.3 HTML og TEI, derimot, er kodesystemer i den betydningen ordet her er brukt. Nærmere bestemt er HTML og TEI eksempler på formelle grammatikker som er utformet i samsvar med de reglene som SGML setter. Det betyr bl.a. at all SGML-programvare skal kunne behandle dokumenter kodet i HTML eller TEI på en fornuftig måte. At det også finnes XML-versjoner av HTML og TEI (henholdsvis XHTML og TEI P4), betyr at disse systemene samsvarer med det subsettet av SGML som defineres av XML.

1.9.4 Det sies av og til at HTML, TEI og andre SGML-baserte kodesystemer er "anvendelser" av SGML. Dersom dette oppfattes i analogi med "anvendelse" av programvare, er det altså litt misvisende. Mer treffende ville det kanskje være å betrakte forholdet mellom systemer som HTML og TEI på den ene siden og SGML på den andre siden i analogi med forholdet mellom et naturlig språk og den språkgruppen som språket hører til. (Da kan vi kanskje også betrakte de forskjellige versjonene av HTML som "dialekter" av "språket" HTML.)

1.9.5 Når det gjelder MECS har vi igjen å gjøre med en formell metagrammatikk, og ikke et spesifikt kodesystem. Også MECS er nemlig slik utformet at det lar seg gjøre å definere forskjellige MECS-baserte kodesystemer. Det ble f.eks. utviklet ett MECS-basert kodesystem for Wittgensteinarkivet (MECS-WIT), og selv om MECS aldri fikk noen utbredelse av betydning, er det også utviklet andre MECS-baserte kodesystemer.

1.9.6 Dette betyr rimeligvis at MECS-baserte systemer har visse felles kjennetegn som skiller dem fra SGML-baserte systemer, og omvendt. Særlig viktig i vår forbindelse fremstår de to systemenes forskjellige løsninger når det gjelder dokumentmaler (dvs. SGMLs DTDer og MECS' CDTer) og overlappende strukturer.

1.9.8 I SGML tar en dokumentmal form av en DTD, som enthvert dokument må kunne knyttes til. [44] En DTD definerer ikke bare hvilke tegn og hvilke elementer som er lovlige i et dokument, men også i hvilke kombinasjoner og rekkefølger disse skal kunne forekomme. Disse reglene uttrykkes i en formalisme på Backus-Naur-form, en type kontekstfri grammatikk. Fordelene med en slik formalisme er som vi allerede har sett mange, men den har en vesentlig begrensning: Den forutsetter at alle elementer er hierarkisk ordnet.

1.9.9 Kontekstfrie grammatikker er velkjente. I informasjonsteknologien finnes det vel etablerte metoder og teknikker for å håndtere hierarkisk ordnede strukturer. For å beskrive strukturer som inneholder overlappende elementer, derimot, må man enten ty til en mindre kjent type kontekstfri grammatikk eller (mest sannsynlig) en kontekstsensitiv grammatikk. Kontekstsensitive grammatikker er mer kompliserte og mindre kjente, og det finnes ikke veletablerte generelle metoder for å formulere eller implementere regler for elementstrukturer i slike grammatikker.

1.9.10 Når utviklerne av SGML ikke har tillatt overlapp, er det altså hverken fordi de har oversett problemet eller fordi de ikke har sett at representasjonen av overlappende strukturer i og for seg kan være meget enkel. Det er fordi de har vurdert prisen som for høy: Dersom man skulle tillate ikke-hierarkiske strukturer ville de ikke kunne beskrives i en kontekstfri grammatikk. Dermed ville man tape det midlet til kontroll over dokumentstruktur som SGMLs DTDer tilbyr.

1.9.11 Nettopp dette kan sies å ha skjedd med MECS (utviklingen av MECS var da heller ikke drevet av noe sterkt ønske om automatisert kontroll over dokumentstruktur). MECS' dokumentmaler, dvs. kodedeklarasjonstabeller (CDT), kan utelukkende benyttes til å deklarere hvilke tegn og elementer som er lovlige i et dokument, men kan ikke uttrykke noe som helst om elementenes innbyrdes forhold.

1.9.12 Det kan altså se ut til å være like gode grunner til at MECS ikke tillater detaljert kontroll over dokumenters elementstruktur som det er for at SGML ikke tillater overlappende elementer: Vil man ha det ene, må man tilsynelatende gi avkall på det andre. Hvor dyptgripende forskjellene mellom MECS og SGML er, ser man kanskje lettest dersom man forsøker å oversette mellom de to systemene.

1.9.13 Å oversette dokumenter fra SGML til MECS er trivielt, og ikke alltid nødvendig. Rent formelt er det nemlig slik at ethvert SGML-dokument er et velformet MECS-dokument. Dette er imidlertid til dels på grunn av at MECS aksepterer en del SGML-mekanismer som har en funksjon i SGML, men ikke i MECS. Dersom man f.eks. ønsker å behandle SGML-dokumenter med MECS-programvare, må man derfor i mange tilfelle oversette dokumentene til en noe annen form. Denne oversettelsen er imidlertid meget enkel. [45]

1.9.14 Å oversette fra MECS til SGML er derimot langt fra trivielt, i alle fall dersom dokumentet inneholder overlappende elementer. [46] Det er hovedsaklig to måter å gjøre dette på: Enten bryter man overlappende elementer opp og representerer dem som punkter og hierarkiske strukturer, eller man benytter SGMLs CONCUR-mekanisme. Det første kan være teknisk komplisert, men er av begrenset prinsipiell interesse. [47] Det siste er av liten praktisk interesse sålenge nesten ingen programmer støtter SGMLs CONCUR-mekanisme, men av desto større teoretisk interesse.

1.9.15 SGMLs CONCUR-mekanisme tillater at et dokument kan knyttes til mer enn én DTD. Dermed kan ett og samme dokument inneholde flere uavhengige hierarkier. Dette betyr i praksis at elementer kan overlappe hverandre dersom de er deklarert i forskjellige DTDer.

1.9.16 Dermed åpner det seg en opplagt mulighet for å oversette MECS-dokumenter til SGML: Man sørger for at hvert eneste element i MECS-dokumentet legges til en egen DTD, og deklarerer en DTD for hvert element i SGML-dokumentet. Denne løsningen har imidlertid åpenbare svakheter: For det første går man da glipp av det som gjerne er motivasjonen for oversettelse: Man reproduserer MECS' frie overlapp, men mister enhver kontroll med dokumentstrukturen. For det andre er det teknisk sett komplisert å operere med så mange DTDer som det da ofte vil være behov for. Bare i de tilfelle der det faktisk er tilfeller av overlapp mellom alle elementtyper i et MECS-dokument er en slik prosedyre på sin plass.

1.9.17 I noen tilfelle er det bare noen få elementer i et MECS-dokument som overlapper med hverandre. La oss for eksempel tenke oss at et MECS-dokument inneholder tre elementtyper, a, b og c, og at a og b i minst ett tilfelle overlapper hverandre, mens c ikke overlapper med noe annet element. Foruten den muligheten som allerede er skissert, nemlig å opprette en egen DTD for hvert av de tre elementene, foreligger da to muligheter: Enten legger man a og c til én DTD og b til en annen, eller man legger b og c til én DTD og a til en annen. Men hvilket alternativ skal man velge?

1.9.18 I andre tilfeller, med hundrevis av elementer med mer kompliserte mønstre av overlapping, blir antallet kombinasjonsmuligheter lett astronomisk. I slike tilfelle vil det f.eks. være nyttig å kunne finne frem til det minste antallet DTDer som er påkrevet. [48] Bare det å regne ut dette tallet har vist seg komplisert, og selv for det minimale antallet DTDer vil det oftest være et stort antall mulige distribusjoner av elementer over DTDer. [49]

1.9.19 Arbeid for å finne algoritmer for løsninger på disse problemene har mye til felles med arbeid innenfor grafteori. Haken er at flere problemer innen dette området står på listen over grafteoriens uløste problemer. Et lignende, men enklere — og mer berømt — problem var the four-color problem. Her var utfordringen å bevise at det aldri er behov for mer enn fire forskjellige farger for å fargelegge et hvilket som helst kart slik at ethvert felt grenser opp mot felt av forskjellig farge. Dette problemet ble formulert av Francis Guthrie i 1852, men fant ikke sin endelige løsning før i 1976 (ved Appel og Haken.) Det beviset som ble funnet baserte seg på så omfattende beregninger at det bare lot seg gjennomføre ved hjelp av moderne tallknusere. Det er derfor fremdeles omstridt blant matematikere.

Noter

[1] Opprinnelig var markup en betegnelse på typografiske instruksjoner som ble gjort i manuskripter før de gikk til trykking. [Ref, f.eks. til ordbok]

[2] F.eks.Microsoft Internet Explorer, Netscape Navigator, Opera osv.

[3] TEI (Text Encoding Initiative vil bli behandlet senere (i 1.5)

[4] MECS (Multi-Element Code System vil bli behandlet senere (i 1.8)

[5] Av disse første 128 tegnene er i sin tur de første 32 (0..31) reservert for såkalte kontrolltegn.

[6] En alfanumerisk streng er strengt tatt en sekvens av bokstaver og tall, men slik uttrykket brukes her regnes også ordmellomrom (blanke) og setningstegn med blant de alfanumeriske.

[7] De markørene som er brukt her er de som vanligvis brukes i SGML — de inngår i den såkalte Reference Concrete Syntax. Disse og andre grunnleggende egenskaper ved et SGML-system defineres i SGML-deklarasjonen. Det er ikke noe i veien for å endre SGML-deklarasjonen slik at elementer som text markeres f.eks. slik: [text]...[|text] eller slik: {text}...{\text}. Det er imidlertid ikke vanlig å endre markørene i Reference Concrete Syntax.

[8] Med unntak av ml, som her er brukt for å markere metriske linjer ("verselinjer"), er alle elementtyper i dette eksemplet hentet fra TEI. (se 1.5) Elementene er imidlertid noe annerledes definert i TEI.

[9] ml-elementene markerer punkter i teksten. Derfor skiller de seg fra andre elementer, som markerer områder, ved at de bare består av enslige " <ml> " som ikke etterfølges av noen avsluttende " </ml> ". (I SGML kalles slike elementer tomme elementer, mens "element" gjerne brukes som felles betegnelse på "tomme" og "vanlige" elementer. Her vil vi bruke betegnelsen innholdselement som betegnelse på ikke-tomme elementer når det er behov for å skille mellom disse og tomme elementer. Vi kan dermed si at innholdselementer har elementinnhold, mens tomme elementer ikke har elementinnhold.) ml-elementene markerer starten på første og slutten på alle etterfølgende metriske linjer. Mer (senere i dette avsnittet) om hvorfor metriske linjer er behandlet på denne måten.

[10] Alle elementtyper i fig 2 og fig 3 er definert, men for at eksemplet i fig 2 skal aksepteres av et SGML-system må vi også definere de to entitetene "ø" og "&aring.". Det kan f.eks. gjøres ved å føye følgende to linjer til DTDen:

  <!ENTITY oslash    "ø"> 
  <!ENTITY aring     "å">

Disse definisjonene er imidlertid systemspesifikke. Dersom vi opererer med Unicodes tegnsett, kan vi i stedet definere på følgende måte:

  <!ENTITY oslash    "&#x00F8;"> 
  <!ENTITY aring     "&#x00E5;">

[11] Faktisk er det i prinsippet uendelig mange dokumenter som oppfyller reglene spesifisert i en slik DTD. For det første tillater den en viss variasjon i elementstrukturen. (I dette tilfellet er DTDen riktignok så strengt definert at det eneste vi kan endre er antall sp-elementer innenfor body-elementet samt innholdet av stage- og ml-elementer innenfor sp-elementene.) For det andre kan elementenes innhold av alfanumeriske data endres vilkårlig. Det er dessuten verdt å merke seg at også det motsatte gjelder— det lar seg gjøre å formulere uendelig mange forskjellige DTDer som et gitt dokument samsvarer med.

[12] Det vi her har kalt "dokument" kalles derfor strengt tatt en dokument-instans i SGML-terminologi. Fullstendig spesifisert består et SGML-dokument av en SGML-deklarasjon og en DTD i tillegg til selve dokument-instansen. Jeg vil likevel bruke "dokument" synonymt med "dokument-instans" i sammenhenger der det ikke synes å kunne lede til misforståelse.

[13] Det er i og for seg ikke noe i veien for å bruke SGML til å kode dokumenters utseende. Dette er imidlertid i alminnelighet frarådet [SGML Handbook...]

[14] Disse eksemplene er alle hentet fra TEI (1.5)

[15] Når jeg sier "generelt" skyldes det at påstanden strengt tatt må kvalifiseres som følger: Et dokument som bruker Reference Conrete Syntax, som ikke inneholder tomme elementer og som ikke benytter noen form for forenkling av merker (om forenkling, se nedenfor) kan parses uten tilgang til noen DTD. Problemet kan dessuten løses ved endring av SGML-deklarasjonen (se avsnittet om XML).

[16] Dokumentet i fig 6 er f.eks. også gyldig dersom vi endrer definisjonen av elementene text, body, sp og ml som følger:

      
  <!ELEMENT text     O O (#PCDATA | front | body | sp | ml)*>
  <!ELEMENT body     O O (#PCDATA | sp | ml | stage)*>
  <!ELEMENT sp       - O EMPTY >
  <!ELEMENT ml       O O  (#PCDATA | ml)* >

Men dokumentstrukturen vil da være en helt annen, og fig 2 og 3 er ikke gyldige i henhold til denne DTDen.

[17] Dette ser altså ut til å være et eksempel på at det som i visse sammenhenger (f.eks. manuell data-innlegging) fremstår som en forenkling, i andre sammenhenger (f.eks. parsing av gyldige dokumenter) fremstår som en sterkt kompliserende faktor.

[18] For ordens skyld må tilføyes at SGML-standarden beskriver en mekanisme som tillater dokumenter å inneholde flere hierarkier. Elementer i slike sameksisterende hierarkier kan overlappe hverandre. Denne mekanismen, som kalles CONCUR, har dessverre vært av liten praktisk betydning. Det er visse tekniske svakheter ved den, og den dag i dag er det ytterst få SGML-programmer som kan håndtere den. Se [Sperberg-McQueen og Huitfeldt 20..] for en diskusjon av bruk av CONCUR til håndtering av overlappende elementer.

[19] Et alternativ ville selvfølgelig være å representere sp som tomme elementer og ml som vanlige elementer — problemet ville immidlertid da bare være forflyttet fra en elementtype til en annen.

[20] Avsnitt og sider er eksempler på andre fenomener som hyppig overlapper. Derfor er det vanlig å markere sideskift med tomme elementer i stedet for å markere sider som elementer. Resultatet er at man lett kan ekstrahere avsnitt, men ikke like lett sider, fra et dokument som er kodet på denne måten.

[21] HTML er basert på HTTP (HyperText Transfer Protocol). HTTP er en såkalt protokoll, dvs et sett av regler som beskriver hvordan informasjon utveksles mellom maskiner i et datanettverk. Det er f.eks. HTTP som definerer URL-formatet (Uniform Resource Locator), som benyttes til å addressere ressurser på Web. Et eksempel på en URL er følgende: http://www.hit.uib.no/mlcd/abstract.html Her angir "http" hvilken protokoll som er brukt, "www.hit.uib.no" angir hvilken maskin dokumentet ligger på, og "mlcd/abstract.html" angir hvor på maskinen dokumentet ligger og hva det heter. Kjennskap til denne adresseringsmetoden er vesentlig for alle som bruker Web. Forøvrig er kunnskap om HTTP i allminnelighet unødvendig for bruk av Web såvel som for forståelse av denne boken.

[22] P-elementet kan sies å være en blandingsvariant: På den ene siden uttrykker det at vedkommende element er en innholdsmessig enhet (et avsnitt), på den annen side ledsages det av en visuell markering, vanligvis en blank linje.

[23] I rettferdighetens navn bør det da også nevnes at vårt Gynt-eksempel kunne vært kodet ved større bruk av innholdsorientert koding dersom vi hadde benyttet oss av denne muligheten.

[24] Et eksempel: I Webs tidligste tider var Mosaic den nærmest enerådende nettleseren. På den tiden var det vanskelig å lage tabeller i HTML. Netscape innførte og støttet koder for tabeller, og Microsoft Explorer fulgte snart etter. Mosaic greide ikke å holde følge, og forsvant snart fra markedet. (Netscape ble derfor kalt en "application killer" [Moulthrop, Aarseth 2000 s...].) Senere har Netscape og Microsoft fortsatt denne konkurransen, samtidig som andre nettlesere har kommet til (f.eks. Opera Fremdeles er det slik at en del HTML-dokumenter "best leses" med den ene eller andre versjonen av den ene eller andre nettleseren

[25] Siden det finnes en rekke forskjellige versjoner av HTML, finnes det rimelig nok også en rekke forskjellige versjoner av HTMLs DTD. Disse versjonene har dog en felles kjerne. Dokumenter som begrenser seg til å bruke denne kjernen, vil være forenlige med alle versjoner, og kunne leses med tilfredsstillende resultat av alle nettlesere. Situasjonen har dessuten stabilisert seg de siste årene, slik at problemet ikke lenger er så fremtredende som det en gang var.

[26] Et annet alternativ er selvfølgelig å overføre programvare eller stilark sammen med data, eller å stole på at brukeren allerede har den programvaren og de stilarkene som trengs. Begge løsninger benyttes i dag, også for dokumenter som ikke er i SGML. Dette skal vi imidlertid ikke gå nærmere inn på her.

[27] Den første versjonen av TEI Guidelines, som ble publisert i 1990, ble kalt P1 og var et utkast. P2 kom i 1992, men ble aldri publisert i trykt form. Den endelige versjonen, P3, kom i 1994. P4, som ble publisert i 2002, er basert på SGMLs subsett XML (se 1.6) men for øvrig, og bortsett fra mindre redaksjonelle endringer, identisk med P3. "TEI" brukes i det følgende avvekslende om det prosjektet som har produsert TEI Guidelines, om TEI Guidelines selv, og om den DTD som spesifiseres av TEI Guidelines

[28] I TEIs terminologi: "tag sets"

[29] Jeg hadde selv stor glede av å få lov til å delta i TEI i perioden 1990-94.

[30] XLL er en standard for lenking. XSL er en standard for stilark.

[31] F.eks. er mekanismene inclusions og exclusions fjernet. Man kan uttrykke regler med inclusions og exclusions som ikke kan uttrykkes uten. En påstand om at XML har beholdt SGMLs uttrykkskraft er derfor strengt tatt ikke helt korrekt, men med det kvalifiserende "for all practical purposes" har Sperberg-McQueen likevel sine ord i behold.

[32] Konkret er XML implementert bl.a. ved å modifisere SGML-deklarasjonen (se 1.3)

[33] Også HTML finnes nå for øvrig i en XML-basert versjon: XHTML

[34] Siden CONCUR (jfr 1.3) er en av de SGML-mekanismene som er fjernet i XML, er det faktisk enda vanskeligere å representere overlappende hierarkier i XML enn i SGML.

[35] Den følgende fremstillingen av MECS er ikke fullstendig. Terminologien er tillempet for denne fremstillingen for å lette sammenligningen med andre systemer beskrevet her. En fullstendig fremstilling av MECS finnes i [Huitfeldt 2000]

[36] Disse strukturene tilsvarer altså SGMLs tomme elementer og innholdselementer.

[37] Det finnes ikke noen enkeltmekanisme i SGML som tilsvarer flerelementer. Fenomener som i MECS representeres ved hjelp av flerelementer vil i SGML typisk kunne representeres enten ved bruk av attributter eller ved bruk av flere nøstede elementer. En forkortelse som i MECS kan kodes slik:

[abb/2\f.eks./abb|for eksempel/abb]

vil i SGML f.eks. kunne kodes slik:

<abb exp="for eksempel">f.eks.</abb>

eller slik:

<exp abb="f.eks.">for eksempel</exp>

eller slik:

<abb><orig>f.eks.</orig><exp>for eksempel</exp></abb>
 Fordi
          attributtverdier i SGML ikke kan inneholde merking, er det bare det siste eksemplet som
          fullt ut tilsvarer MECS-kodingen.

[38] De tre gjenstående kodestrukturene er:

Polyelementer, som kan markeres slik:

[tag| ... /tag| ... /tag]

Entitet-attributter, som markeres slik:

{...\tag}

Kommentarer, som markeres slik:

<| ... |>

Polyelementer utgjør sammen med flerelementer det som i MECS går under den felles betegnelsen multielementer. Forskjellen mellom dem er at mens de enkelte forekomstene av polyelementer i en tekst kan ha varierende antall elementer, må alle forekomster av flerelementer alltid ha samme antall elementer.
Entitet-attributter brukes typisk til å angi den spesifikke betydningen eller funksjonen til individuelle forekomster av tegn. Vi kan f.eks. tenke oss at tegnet "&" i en tekst brukes avvekslende som forkortelse for "og" og som den logiske operatoren for konjunksjon, mens denne i sin tur av og til angis ved "." Det kan da være behov for å disambiguere forekomster både av "&" og ".", noe som f.eks. kan gjøres slik:

  {amp\og}    for & brukt som forkortelse for "og"
  {amp\con}   for & brukt som logisk operator for konjunksjon
  {p\fs}      for punktum brukt som setningstegn (fs for "full stop")
  {p\con}     for punktum brukt som logisk operator for konjunksjon

Den siste kodestrukturen er kommentarer. Kommentarer er elementer som skal ignoreres av parsere. Tilsvarende markeres kommentarer i SGML slik: " <!–– ... ––> "

[39] MECS-deklarasjonen er altså en systemdeklarasjon, og kan delvis sies å tilsvare en SGML-deklarasjon. Markørenes forskjellige funksjoner deklareres gjennom deres rekkefølge i MECS-deklarasjonen. Markørene kan derfor om ønskelig endres. I denne fremstillingen er MECS' "standardnotasjon" benyttet.

[40] På dette punktet foregriper MECS altså XML. Som nevnt (i 1.5) er det nettopp endringen av markører som gjør "vanlige" startmerker forskjellige fra "tomme elementer" i XML, og som dermed gjør det mulig både å parse XML-dokumenter uten tilgang til en DTD og å operere med et begrep om velformede så vel som gyldige XML-dokumenter.

[41] Det er dermed mulig å foreta en systematisk sammenligning av dokumenter på grunnlag av deres minimale CDTer. Dersom et dokument samsvarer med den minimale CDTen til et annet dokument er f.eks. kodesystemet til det første dokumentet enten identisk med eller et subsett av det andre dokumentets kodesystem. Man kan også bruke en CDT omtrent på samme måte som man bruker en stavesjekker: Først genererer man en CDT automatisk, så redigerer man dokumentet og føyer evt. nye elementer til, dernest sjekker man det redigerte dokumentet mot den opprinnelige CDT for å avgjøre om eventuelle nye elementer og tegn skal betraktes som feil eller inkluderes i en ny CDT.

[42] Bl.a. programvare for validering, formattering, stilark-basert reformattering for presentasjon på skjerm eller i trykt form, enkel statistikk, indeksering, elementekstraksjon og redskaper for analyse av elementstruktur. Programvaren hadde imidlertid ikke noe moderne grafisk brukergrensesnitt og har ikke blitt vedlikeholdt på mange år.

[43] En del slike mekanismer er beskrevet i [...]

[44] I XML er det riktignok ikke noe krav om at man faktisk knytter et dokument til en DTD, men også for ethvert XML-dokument kan det knyttes en DTD.

[45] Oversettelse tilbake til SGML er også triviell, så fremt man ikke i mellomtiden har benyttet noen av de MECS-spesifikke mekanismene i dokumentet.

[46] Å oversette MECS-dokumenter uten overlapp til SGML er like trivielt som å oversette SGML-dokumenter til MECS.

[47] Helt uten interesse er det dog ikke — man kan f.eks. spørre seg hvorfor man ikke skulle være like tilfreds med en teknisk komplisert som med en enklere løsning, sålenge resultatet er det sammme.

[48] Selv om det selvsagt ikke nødvendigvis er slik at man i ethvert tilfelle vil finne at en av distribusjonene over et minimalt antall DTDer er den mest hensiktsmessige.

[49] Se [Sperberg-McQueen og Huitfeldt 1999] for en nærmere drøfting av de tekniske sidene ved problemet.

Claus Huitfeldt: Tekster og tekstkoding — Kap 01

Innhold

Tekstkoding

1.1 Tekstkoding forklart i all enkelhet

1.2 Datamaskiner, tekster og kodesystemer

1.3 Standard Generalized Markup Language (SGML)

1.4 HyperText Markup Language (HTML)

1.5 Text Encoding Initiative (TEI)

1.6 Extensible Markup Language (XML)

1.7 XML-teknologi

1.8 Multi-Element Code System (MECS)

1.9 Forholdet mellom SGML og MECS

Noter