Om dokumentet | HTMLs svakheter | Om XML | XMLs muligheter | Kilder og referanser
English version | Svensk version | Andre artikler
Dette er noe min veileder ba meg skrive i forbindelse med hovedfagsoppgaven min. Jeg tenkte imidlertid at flere enn oss kunne ha glede av dette og la det ut på web. Dokumentet er skrevet i helt "ren" HTML, uten layoutbeskrivelser av noe slag. Layout er i stedet angitt med et CSS-stylesheet, noe som gjør at du må ha Netscape 4.0, Amaya, GNUscape Navigator eller MSIE 3.0 for å kunne se dokumentet i sin fulle prakt. Det skulle imidlertid være helt greit å lese uansett.
Hvis du ikke vet hva som er forskjellene på en tag og et element i SGML bør du se på ordforklaringene nederst.
Opprinnelig var det meningen at når man skrev HTML skulle man bruke elementene til å markere informasjonen etter dens betydning, ikke etter hvordan man ønsket at sidene skulle se ut i en eller annen vevleser. Med andre ord skulle man plassere tittel, hovedoverskrift, tekst som skulle framheves og kontaktinformasjon til forfatter av siden i henholdsvis elementene TITLE, H1, EM (evt STRONG) og ADDRESS. Å i stedet bruke FONT og I eller lignende ødelegger for bruk av informasjonen til både fremvisning i vevleser og maskinell behandling. (Se referanse 1.)
Når man fulgte den opprinnelige hensikten kunne browseren selv tilpasse hvordan den ville vise de forskjellige delene av siden etter leserens omgivelser og innstillinger. Dette er nyttig fordi noen lesere er blinde, noen kjører ikke-grafiske vevlesere og noen har endret innstillingene for hvordan f.eks. overskrifter skal vises. Alt dette gjør at en forfatter som ikke følger reglene kan skape krøll for de av leserene som har et ikke-standard miljø.
Dessverre har vevleser-leverandørene enten ikke forstått dette eller bevisst valgt å ignorere dette, for de har ignorert standarder som forsøkte å legge layoutinformasjon utenfor selve HTML-dokumentene, som f.eks. CSS. (Se referanse 2.) I stedet har de laget sine egne elementer og attributter som kun har til hensikt å angi layout, som FONT, CENTER, BGCOLOR osv. De har også laget HTML-redigeringsverktøy (f.eks. Netscape Gold) som produserer HTML der taggingen er lagt på med tanke på layout i stedet for innhold. (F.eks. bruker Netscape Gold UL til å lage indentering, og ikke bare for å markere lister.)
Resultatet er at svært mange sider på web nå inneholder tagging som er beregnet på en bestemt versjon av en bestemt vevleser (med standard innstillinger) i en bestemt skjermoppløsning, og som ofte er mer eller mindre uleselig for de som bruker noe annet. HTML har gradvis blitt vridd om til et layoutspråk for Netscape og MSIE av leverandørene og deres brukere.
Dette er imidlertid ikke det eneste problemet. Dersom man skal merke informasjonen etter betydning og være virkelig presis strekker ikke HTML til lenger. Kjemikere vil kanskje ha elementer for å markere formler, måleverdier osv, mens flyprodusenter vil snakke om motor, del, modell osv. Dersom man tenker litt over dette skjønner man fort at om HTML skal kunne dekke alles behov vil det kreve et vanvittig antall elementer, og det er ganske enkelt ikke noen god løsning, hverken teknisk eller menneskelig. (Tungt å lære og lage programvare for.)
HTML har også svært lite intern struktur, slik at man kan lett skrive lovlig HTML som ikke henger på greip i det hele tatt hvis man ser på betydningen til elementene. Dette er blant annet fordi innholdet til BODY har blitt definert slik at man står helt fritt med hvordan man vil plassere elementene i forhold til hverandre. Dette gjør at man ikke er nødt til å ha en struktur der H1 kommer først, så H2'er under H1, og H3'er under H2 osv. (Tenk deg H1 som bokoverskrift, H2 som del-overskrift, H3 som kapitteloverskrift og H4 som underkapittel osv.) Slik burde det logisk sett være, men HTML krever altså ikke det. (Se referanse 1 og 3.)
Disse problemene har vært kjent lenge, og sommeren '96 begynte W3C (som lager standardene på web) arbeidet med å lage en standard som kunne løse disse problemene. Den nye standarden heter XML, for eXtensible Markup Language. Arbeidsgruppen (heretter kalt XWG, for XML Working Group)) har delt arbeidet sitt inn i tre faser.
Fase 1 er nå fullført, XML-standardens versjon 1.0 er ferdig. Fase 2 er underveis, og i fase 3 har man såvidt fått frem et forslag.
Vær klar over at beskrivelsene som gis under er forenklede og bare ment å gi et inntrykk av XML. De utelater mye av standardene og er litt unøyaktige. Vil du ha mer nøyaktig informasjon bør du heller se på tilleggene lenger nede. Vær også oppmerksom på at disse standardene ikke er endelige, slik at de kan endre seg før de blir tatt i bruk, og at dette dokumentet derfor kanskje ikke gjelder når standardene er ferdige. Som en første innføring skulle det imidlertid være helt greit.
Det finnes allerede en standard som kan brukes til å definere markeringsspråk som HTML, og den heter SGML. HTML er faktisk definert i SGML. I teorien kunne jo SGML vært brukt som den nye standarden, slik at man kunne utvidet vevleserene med SGML-forståelse. Problemet er bare at SGML er stort og komplisert å implementere, og inneholder mange muligheter som ikke brukes og aldri har blitt implementert. Dessuten har SGML litt for svak støtte for forskjellige tegnsett, noe som kan skape problemer på web der man ofte ikke vet hvilket tegnsett et dokument er skrevet i. Det er også vanskelig å tolke et SGML-dokumenent uten å ha definisjonen av markeringsspråket (DTD-en) tilgjengelig. Resultatet ble altså at XWG valgte å lage en forenklet utgave av SGML, som de kalte XML. (Som de liker å si selv er altså XML mer SGML light enn HTML++.)
Hovedpoenget med XML er at man, ved å definere sitt eget markeringsspråk, kan kode informasjonen i dokumentene etter betydning på en langt mer presis måte enn det HTML tillater. Det gjør at programmer som behandler dokumentene kan "forstå" dem og gjøre ting med informasjonen på en helt annen måte enn med vanlig HTML (eller tekstbehandler-dokumenter). Et eksempel er om man kodet matoppskrifter i henhold til en DTD skreddersydd for dette der det var angitt mengde av hver ingrediens og alternativer til enkelte ingredienser. Da kunne man lett lage et program som tok en oversikt over hvilke ingredienser man hadde i kjøleskapet og laget en liste over de rettene man kunne lage med dem. Gitt kalori-informasjon om alle ingredienser kunne systemet også foreslå de variantene av oppskriftene som hadde færrest kalorier og sortere forslagene i listen over på kalori-innhold. Mulighetene er nesten ubegrenset, fordi informasjonen er kodet på en måte som programmene kan forstå.
Å definere sitt eget markeringsspråk i XML er faktisk forbausende lett. Hvis vi for eksempel vil lage et eget markeringsspråk for FAQ-er vil vi kanskje at det skal kunne brukes omtrent slik:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<!DOCTYPE FAQ SYSTEM "FAQ.DTD">
<FAQ>
<INFO>
<SUBJECT> XML </SUBJECT>
<AUTHOR> Lars Marius Garshol</AUTHOR>
<EMAIL> larsga@ifi.uio.no </EMAIL>
<VERSION> 1.0 </VERSION>
<DATE> 20.jun.97 </DATE>
</INFO>
<PART NO="1">
<Q NO="1">
<QTEXT>Hva er XML?</QTEXT>
<A>SGML light.</A>
</Q>
<Q NO="2">
<QTEXT>Hva kan jeg bruke det til?</QTEXT>
<A>Hva du vil.</A>
</Q>
</PART>
</FAQ>
I XML ville markeringsspråket over (la oss kalle det FAQML) hatt denne DTDen:
<!ELEMENT FAQ (INFO, PART+)>
<!ELEMENT INFO (SUBJECT, AUTHOR, EMAIL?, VERSION?, DATE?)>
<!ELEMENT SUBJECT (#PCDATA)>
<!ELEMENT AUTHOR (#PCDATA)>
<!ELEMENT EMAIL (#PCDATA)>
<!ELEMENT VERSION (#PCDATA)>
<!ELEMENT DATE (#PCDATA)>
<!ELEMENT PART (Q+)>
<!ELEMENT Q (QTEXT, A)>
<!ELEMENT QTEXT (#PCDATA)>
<!ELEMENT A (#PCDATA)>
<!ATTLIST PART NO CDATA #IMPLIED
TITLE CDATA #IMPLIED>
<!ATTLIST Q NO CDATA #IMPLIED>
<!ELEMENT> brukes til å definere elementer på følgende måte:
<!ELEMENT ELEMNAVN ELEMINNHOLD>. ELEMINNHOLD beskriver hvilke
elementer som har lov å forekomme inne i elementet vi har definert, og på
hvilken måte. A,B betyr at A må komme først, og så B. ? etter et
element betyr at den kan utelates, + betyr at den skal være med en eller mange
ganger og * betyr at den ikke behøver å være med og at den kan gjentas. (* er på en måte + og ?
kombinert.)
#PCDATA står for vanlig tekst (noe forenklet).
En viktig forskjell mellom XML og SGML er at elementer i XML som ikke har
innhold (som f.eks. IMG eller BR i HTML) skal skrives slik i XML:
<IMG SRC="pamela.gif"/>. Merk skråstreken før den avsluttende
>'en. Dette gjør at et program som leser dokumentet uten å kjenne DTD-en vet at
dette elementet ikke har noe innhold, slik at det ikke behøver å se etter en
slutt-tag og slik at det vet at det som kommer etter tag'en ikke er inne i
elementet.
<!ATTLIST> brukes til å angi hvilke attributter et element kan
ha. I DTD-en ovenfor brukes de til å si at PART og Q har en attributt som
heter NO, som inneholder vanlig tekst og som kan utelates. Som du ser har PART
to attributter, den siste heter TITLE, inneholder tekst og kan utelates.
HyTime er en standard som (blant annet) angir hvordan linking mellom forskjellige SGML-dokumenter kan gjøres. Den er langt mer avansert enn linkingen i HTML og inneholder mye som man ikke har bruk for på web. XWG holder derfor på å lage en tilsvarende standard for XML som låner mye fra HyTime og tilsvarende standarder, men forenkler det.
For at man skal kunne bruke denne linkstandarden i en hvilken som helst DTD er det ikke definert noen egne elementer for dette. I stedet er det slik at linkende elementer bruker et eget attributt som identifiserer dem som linkende. Alle elementer som har et attributt XML-LINK vil bli oppfattet som linkende. Verdien til XML-LINK angir hva slags type link det er.
Linker i XML kan gå mellom to eller flere ressurser der ressurser kan være enten filer (og ikke nødvendigvis XML eller HTML-filer) eller elementer i filer. Linker kan settes opp ved hjelp av ACTUATE-attributtet slik at de enten følges når brukeren ber om det (ved å klikke eller på annen måte, verdi USER) eller automatisk (dvs: i det systemet leser det linkende elementet, AUTO). Hva som skjer når man følger en link i XML angis med SHOW-attributtet, som kan ha følgende verdier:
XML har også mer avanserte linker enn dette. Linker kan gå til mer enn en ressurs, linker kan angis utenfor dokumentene de linker og hvilket element i en ressurs en link går til kan angis på svært avanserte måter. Elementet kan identifiseres med et ID-attributt, posisjon i element-strukturen og man kan til og med angi ting som at linken skal gå til "fjerde UKAPITTEL-element i tredje KAPITTEL-element i første DEL".
I FAQML kunne dette blitt brukt både for å angi linker ut av dokumentet til relevant informasjon og til å angi interne forhold mellom forskjellige svar. Fotnoter kunne også vært angitt med slike ting.
Faktisk finnes det allerede en SGML-standard for dette også, som heter DSSSL, og den er heller ikke enkel. Følgelig har XWG også her bestemt seg for å lage en forenklet utgave. Nøyaktig hva de velger er ikke klart enda, men et forslag kalt XSL er lagt frem. Om det blir akseptert er foreløbig uklart, så jeg beskriver i stedet DSSSL, og så til slutt hva som antagelig blir forskjellen på disse.
DSSSL er faktisk et programmeringsspråk basert på Scheme (en dialekt av LISP,) og har muligheter for å gjøre svært avanserte ting med SGML-dokumentet det bearbeider. Hvis man vil kan man bruke det som et enkelt stylesheet som angir fonter og fontstiler for de forskjellige elementene. Siden DSSSL er basert på Scheme kan man nokså enkelt også utvide dette til kraftigere saker.
DSSSL brukes som regel til å gjøre SGML om til et mer egnet presentasjonsformat som for eksempel PDF (også kjent som Acrobat), PostScript, LaTeX, HTML eller RTF (Microsoft Rich Text Format). Layouten kan man beskrive ganske nøyaktig og DSSSL har svært avanserte muligheter.
Under skal jeg forsøke å vise hvordan et stylesheet for FAQML kan lages, men uten å forklare så veldig mye av det som inngår. Jeg har delt inn filen i deler for å kunne skyte inn forklaringer etterhvert, men det er altså snakk om en sammenhengende fil.
DSSSL består av flere deler, der den grunnleggende er uttrykkspråket som skriver seg fra Scheme. Dette gjør at alle DSSSL-stylesheet egentlig er ett stort Scheme-uttrykk som beregnes av DSSSL-motoren og gir en eller annen fil som resultat. En annen viktig del er stil-språket, som er nesten det eneste jeg har brukt her. (Uttrykksspråket er kun brukt til ganging av skriftstørrelse.) En tredje del er et spørrespråk som kan brukes for å finne de elementene man er ute etter i en SGML-fil. Jeg har brukt det under for å finne nummeret til et FAQ-spørsmål inne i QTEXT-elementet, selv om nummeret er angitt på Q-elementet som ligger rundt.
All formatering i DSSSL gjøres med såkalte flytobjekter, og under ser man
en rekke (element X (make Y-uttrykk som angir at når element
X dukker opp skal et flytobjekt av type Y lages. Deretter angis stilregler
for Y og til slutt innmaten i Y. Det er mye mye mer ved DSSSL enn dette,
men jeg synes det jeg har beskrevet her allerede er nesten for mye.
<!doctype style-sheet PUBLIC "-//James Clark//DTD DSSSL Style Sheet//EN"> ;--- DSSSL stylesheet for FAQML ;---Konstanter (define *font-str* 12pt) (define *font* "Times New Roman")
Dette angir bare SGML-DTD-en for DSSSL som jeg har brukt og definerer to
konstanter som jeg bruker lenger ned. Tanken med dette er at om jeg plutselig
skulle få lyst til å gjøre all skriften i dokumentet litt større kan jeg endre
*font-str* til 13 uten å måtte gå gjennom hele filen. Etter et
semikolon (;) blir resten av linjen ignorert.
;---Elementhåndtering (element FAQ (make simple-page-sequence font-family-name: *font* font-size: *font-str* input-whitespace-treatment: 'collapse line-spacing: 14.4pt (process-children)))
Denne delen sier at all tekst i FAQ-en skal være i fonten *font*,
og i størrelsen *font-str* hvis ikke annet er angitt. Jeg sier
også at whitespace (dvs: mellomrom, linjeskift og tabs) er ubetydelig, akkurat
som i HTML og angir linje-høyden. process-children betyr at nå
skal alle elementer inne i FAQ-elementet behandles med disse verdiene.
(element INFO (make paragraph quadding: 'center space-after: 18pt (process-children)))
Dette angir at elementet INFO (fra start-tag til slutt-tag) skal danne et avsnitt som skal være sentrert og ha 18 punkters mellomrom etter seg. Deretter behandles barna (dvs elementene inne i INFO).
(element SUBJECT (make paragraph font-size: (* *font-str* 2) line-spacing: (* *font-str* 2) space-after: 24pt (process-children)))
SUBJECT-elementet skal altså vises i dobbel skriftstørrelse (som du ser setter jeg font-size til det dobbelte av *font-str*) og dobbel linjehøyde og med 24 punkter mellomrom etter. AUTHOR og EMAIL er forenklede utgaver av dette, så jeg hopper over dem.
(element VERSION (make paragraph (make sequence (literal "Versjon: ")) (process-children)))
For VERSION lager jeg et sekvens-flytobjekt der jeg setter inn tekst-konstanten "Versjon:" før innholdet i elementet behandles. Resultatet er altså at teksten Versjon: vises foran versjonsnummeret i avsnittet som lages. DATE er akkurat tilsvarende, så jeg hopper over den.
(element PART (make paragraph font-size: (* *font-str* 1.5) line-spacing: (* *font-str* 2) (make sequence (literal (attribute-string "NO" (current-node))) (literal ". ") (literal (attribute-string "TITLE" (current-node))) ) (process-children)))
Jeg ville at PART skulle vises i en stor font, med nummer og tittel, omtrent slik: "1. Grunnleggende XML". Dermed må jeg bruke sequence for å få satt inn denne teksten før innholdet i PART. Funksjonen attribute-string gir meg verdien til atributtet NO og så setter vi inn ". " etter NO og tittelen til slutt. Resten er så enkelt at det hopper jeg over.
Dersom noen vil se det har jeg lagt ut hele DSSSL-filen her, sammen med resultatet i RTF- og PostScript-format. RTF-filen er produsert med Jade (se referanse 12) og PostScript-filen er produsert fra denne igjen.
Slik det ser ut nå vil ikke XSL bygge på Scheme, fordi Netscape, Microsoft og andre allerede støtter ett programmeringsspråk i vevleserne sine (JavaScript), slik at man heller vil bruke det. Dermed ser det ut til at XSL vil bli definert som en XML-DTD, og at eventuell programmering gjøres i JavaScript. Ellers vil XSL ha den samme formateringsmodellen som DSSSL, men litt forenklet og mindre kraftig. (JavaScript er forøvrig også et mindre kraftig språk enn det Scheme er.)
Vær klar over at dette er vill og uhemmet synsing om WWWs framtid slik at alt bør tas med en klype salt. (Referanse 4 er en ypperlig artikkel av XWGs formann Jon Bosak om hva XML kan brukes til.)
Det første jeg håper XML kan rette på er problemene med å lage websider med skikkelig layout som er leselige for alle. I og med at XSL vil være en fullt ferdig standard som må støttes vil man etterhvert kunne regne med å ha en fast stabil standard man kan skrive mot. DSSSL-O er også så avansert at man i stylesheet'ene sine kan lage kode som tester om egenskapene man bruker er støttet av leserens vevleser og bruke alternative løsninger om de ikke er det.
En FAQ-vedlikeholder vil også slippe problemene forbundet med å vedlikeholde en FAQ i HTML, .txt og PDF-versjoner. I stedet kan han/hun lage et (eller flere) DSSSL-stylesheet som kan kjøres hver gang XML-originalen er oppdatert og automatisk få oppdaterte filer i de andre formatene. (Slik jeg produserte .RTF og .PS-filer fra FAQ'en min lenger opp.)
I og med at hverken Microsoft eller Netscape har klart å implementere CSS skikkelig kan man jo lure på hvordan det skal gå når de skal prøve seg på DSSSL. Håpet er at de nå vil bli nødt til å gjøre en skikkelig jobb og skrive vevleserene sine omigjen fra bunnen av, og at om de ikke gjør det så vil noen andre se sitt snitt til å gjøre en bedre jobb og overta markedet. De har nå lovet å støtte XML, så det er grunn til å håpe, men heller ikke mer... (Se referanse 5 og 6.)
Et API for XML og HTML som alle XML/HTML-prosessorer (dvs vevlesere og andre verktøy) kan/bør støtte (kalt Document Object Model, eller DOM) er under utarbeidelse. Det foregår litt på siden av XWGs arbeid, men er likevel godt i gang. (Se referanse 7.) Dette API-et vil gjøre at man kan lage Java-applets (eller JavaScript-biter) som kan brukes til å endre fremvisningen av XML-kodet informasjon i vevleserene. (Medlemmene i XWG liker å kalle dette "giving Java something to work with".)
Dette kan brukes på utallige måter, men eksempler på det man tenker seg er fotnoter som ikke synes før du trykker på henvisningen, at man kan få opp bare kapitteloverskriftene i et stort dokument og så klikke på et kapittel for å underkapitteloverskriftene i et (eller alle) kapitler og så klikke på underkapittelet for å se innholdet. Man kan også lage ting som tabeller som man kan endre sorteringen på ved å klikke på kolonnen man vil ha sortert. Mulighetene er som sagt utallige og dette er bare toppen av isfjellet.
Dette kan gjøres vesentlig mer avansert. For eksempel kan VRML (språk for koding av tre-dimensjonale verdner) redefineres som et XML-språk og VRML-visere kan gjøres som Java-applets som bruker DOM. (Hvis du tror dette er science fiction så ta en titt på referanse 8.) Dette vil så gjøre at man kan bruke VRML slik det opprinnelig var tenkt brukt, men uten å behøve noe mer programvare enn vevleseren sin. (Og appletene, men de "installerer" seg jo selv.)
Jon Bosak skriver i referanse 4 om en enda mer avansert mulighet. De største produsentene av elektroniske komponenter (såkalte chips) har gått sammen om å lage en DTD som kan brukes til å beskrive komponenter. Sammen med noen Java applets kan man bruke dette til å laste ned beskrivelser av forskjellige kretser og så modellere hvordan disse virker sammen.
Anvendelsene som beskrives her er foreløbig litt langt fram i tid, men jeg har håp om at de kan bli virkelighet etterhvert.
At informasjonen i XML-dokumenter er så nøyaktig beskrevet med markeringene gjør at man kan søke på helt andre måter enn de primitive tekst-søkene som søkemotorer som Excite og Altavista tilbyr i dag. Det er allerede laget SGML-søkespråk som har funksjonalitet som kan minne om SQL og det forskes en del på dette. (Se referansene 9 og 10.)
Med standardiserte DTDer for forskjellige formål vil man kunne søke opp informasjon med langt større nøyaktighet enn det som er mulig i dag. For eksempel vil en sentral søketjeneste for kretsfabrikantene kunne bygge på DTDen jeg snakket om lenger opp og tilby søk i kretsbeskrivelsene til mange forskjellige fabrikanter. Dermed kunne man gjøre svært nøyaktige søk på kretser etter spesifikasjoner, omtrent som om man hadde en vanlig relasjonsdatabase.
Å utnytte dette for globale søketjenester som Excite og Altavista vil bli vanskeligere, fordi disse vil bli nødt til å ta hensyn til alle mulige DTDer som finnes. Med en oversikt over de viktigste og litt kunstig intelligens i søkeverktøyene kunne dette la seg håndtere, men foreløbig er dette fullstendig i det blå.
Jon Bosak snakker om å utnytte dette i forbindelse med intelligente agenter, som altså er personlige webroboter som raser rundt på nettet og leter etter informasjon til deg personlig etter dine innstillinger. Disse vil kanskje ha større muligheter for å lykkes, fordi kunstig intelligens-delen her vil være lettere å få til (tror jeg) og fordi det vil bli lettere å håndtere problemet med forskjellige DTDer.
Fordi en DTD angir et standardformat for informasjon for en bestemt anvendelse gjør dette det langt lettere å gjøre informasjonsveksling mellom ulike parter. Systemer som kan konvertere mellom sitt interne format og en felles DTD vil kunne dele informasjon med hverandre selv om de altså har hvert sitt proprietære dataformat.
Dette gjør at data lett kan flyttes fra en database til en annen, uavhengig av hvilket system disse databasene faktisk benytter seg av internt. På web vil dette være svært interessant for datautveksling mellom firmaer som driver i samme bransje, eller mellom forskere innen et fagfelt.
Det for eksempel allerede utviklet et eget XML-språk for kjemikere, kalt CML. (Se referanse 11.) Dette vil være svært aktuelt for utveksling av data om kjemiske forskningsresultater og data mellom kjemikere og bedrifter som arbeider med kjemi på en eller annen måte. Det kan også brukes sammen med Java-applets i undervisning. Mulighetene er ganske enkelt svimlende.