Om dokumentet | HTMLs svagheter | Om XML | XMLs möjligheter | Källor och referenser
Norsk versjon | English version | Andra artiklar
Detta dokument är något min handledare bad mig skriva i samband med min avhandling, för att enkelt förklara vad XML är för något. Jag tänkte emellertid att fler än bara vi skulle kunna ha glädje av detta och har därför lagt ut det på nätet. Dokumentet är skrivet i helt "ren" HTML, utan layoutbeskrivningar av något slag. Layouten är i stället angiven med en CSS-stilmall, något som gör att du måste använda Netscape 4.0, Amaya, GNUscape Navigator eller MSIE 3.0 för att kunna se dokumentet i sin fulla prakt. (Det är läsbart även i äldre läsare men ser snyggare ut med CSS.)
Om Du inte vet skillnaden på en tagg och ett element i HTML/SGML bör Du se efter i ordlistan nederst.
Från början var det tänkt att när man skrev HTML så skulle man använda elementen till att markera informationen efter dess betydelse, inte efter hur man önskade att sidan skulle se ut i en eller annan webbläsare. Med andra ord skulle man placera titel, överskrift, text som skulle framhäves och kontaktinformation till sidans författare inuti elementen TITLE, H1, EM (eller STRONG) och ADDRESS. Att i stället använda FONT och I eller liknande element omöjliggör bruk av informationen till både visning i webbläsere och maskinell behandling. (Se referens 1.)
Om man följde den ursprungliga avsikten så skulle webbläsaren själv kunna avgöra hur den vill visa de olika delarna av sidan beroende på yttre faktorer och inställningar. Detta vore bra eftersom några läsare är blinda, några använder icke grafiska webbläsare och några har ändrat inställningarna för hur t.ex. överskrifter skall visas. Allt detta gör att en författare som inte följer reglerna kan skapa problem för de av läsarna som har en icke-standard miljö.
Dessvärre har webbläsar-tillverkarna antingen inte förstått detta eller medvetet valt att ignorera detta, för de har ignorerat standarder som forsökt att lägga layoutinformationen utanför själva HTML-dokumentet, som t.ex. CSS. (Se referens 2.) I stället har de lagt till egna element och attribut som bara har till avsikt att ange layout, som FONT, CENTER, BGCOLOR osv. De har också skapat HTML-redigeringsverktyg (t.ex. Netscape Gold) som producerar HTML där taggningen är vald med tanke på layout istället för innehåll. (T.ex. använder Netscape Gold UL till att skapa indrag, och inte bara för att markera listor.)
Resultatet är att det stora flertalet webbsidor nu innehåller taggning som är speciellt avstämd för en viss version av en webbläsere (med standard inställningar) och en viss skärmupplösning, och som ofta är mer eller mindre oläslig för de som använder något annat. HTML har av tillverkare och användare gradvis ändrats om till att bli ett layoutspråk för Netscape och MSIE.
Detta är emellertid inte det enda problemet. När man skall märka informationen efter betydelse och vara verkligen precis då räcker HTML inte längre till. Kemister vill kanske ha element för att markera formler, mätvärden osv, medan flygplansproducenter vill prata om motor, del, modell osv. När man funderar lite över detta finner man snart att om HTML skall kunna täcka alla behov så skulle det krävas ett vanvettigt stort antal olika element, och det är naturligtvis ingen bra lösning, varken tekniskt eller mänskligt. (Jobbigt att lära och skapa programvaror för.)
HTML har också mycket lite intern struktur, så att det är helt möjligt att skriva korrekt HTML som saknar sammanhang om man tittar på elementens betydelse. Detta beror på att innehållet i BODY har blivit definierat som att det står en helt fritt hur man vill placera de olika elementen i förhållande till varandra. Detta gör att man inte är tvungen att ha en struktur där H1 kommer först, därefter H2 under H1, och H3 under H2 osv. (Tänk dig H1 som boktitel, H2 som överskrift, H3 som kapitelöverskrift och H4 som underkapitel osv.) Rent logisk borde det vara så, men HTML kräver alltså inte detta. (Se referens 1 och 3.)
Dessa problem har varit kända länge, och sommaren '96 började W3C (som beslutar om standarden på webben) arbetet med att skapa en ny standard som skulle lösa dessa problem. Den nya standarden heter XML, för eXtensible Markup Language. Arbetsgruppen (härefter kallad XWG, efter XML Working Group) har delat upp sitt arbete i tre faser.
Fas 1 är nu slutförd, XML-standardens version 1.0 är färdig och i fas 2 arbetar man med ett utkast. Även i fas 3 har man nu fått fram ett förslag.
Var klar över att beskrivningarna som ges nedan är förenklade och bara är till för att ge ett intryck av XML. De utelämnar mycket av standarden och är lite oexakt. Vill Du ha mer exakt information bör du titta på tilläggen längst ned på sidan. Var också uppmärksam på att dessa standarder inte är slutgiltiga, och att de kan ändra sig innan de tas i bruk, och att detta dokument därför kanske inte gäller när standarden är färdig. Som en första introduktion bör det emellertid vara användbart.
Det finns redan en standard som kan användas till att definera markeringsspråk som HTML, och den heter SGML. HTML är faktiskt definierat i SGML. I teorin skulle ju SGML kunna användas som den nye standarden, och man skulle bara behöva förse webbläsarna med SGML-förståelse. Problemet är bara att SGML är stort och komplicerat att implementera, och innehåller många möjligheter som mycket sällan eller rent av aldrig behövs. Dessuten har SGML lite för svagt stöd för olika teckenspråk, något som kan skapa problem på webben där man ofta inte vet vilket teckenspråk ett dokument är skrivet i. Det är också osäkert att tolka ett SGML-dokument utan att ha definitionen av markeringsspråket (DTD'n) tillgänglig. Resultatet blev alltså att XWG valde att skapa en förenklad version av SGML, som de kallade XML. (Som de brukar säga är XML mer som "SGML light" än "HTML++".)
Huvudpoängen med XML är att man, genom att definiera sitt eget markeringsspråk, kan koda informationen i dokumenten efter betydelse på ett långt mer precist sätt än vad HTML tillåter. Detta gör att programmen som behandlar dokumenten kan "förstå" dem och göra saker med informationen på ett helt annat sätt än med vanlig HTML (eller textbehandlar-dokument). Ett exempel är om man kodat maträtter i enlighet med en DTD - skräddersydd för detta ändamål - där det var angivit mängden av varje ingrediens och alternativ till vissa ingredienser. Då kunde man enkelt skapa ett program som tog en sammanställning av vilka ingredienser som fanns i kylskåpet och skapa en lista över de rätter man kan laga med dem. Givet kalori-information till alla ingredienser kan systemet också föreslå de maträtter som har minst kalorier och sortera förslagen i listan efter kalori-innehållet. Möjligheterna är nästan obegränsade, eftersom informationen är kodad på ett sätt som programmerna kan förstå.
Att definiera ett eget markeringsspråk i XML är faktisk överraskande lätt. Om vi till exempel vill skapa ett eget markeringsspråk för FAQ-er så vill vi kanske att det skall kunna användas på detta vis:
<?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>Vad är XML?</QTEXT>
<A>SGML light.</A>
</Q>
<Q NO="2">
<QTEXT>Vad kan jag använda det till?</QTEXT>
<A>Vad du vill.</A>
</Q>
</PART>
</FAQ>
I XML skulle markeringsspråket ovan (låt oss kalla det FAQML) ha denna DTD:
<!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> används till att definiera elementen på följande vis:
<!ELEMENT NAME CONTENT>. NAME anger namnet på elementet, CONTENT beskriver vilka
element som får förekomma inne i elementet vi har definierat, och på vilket sätt. A,B betyder att A kommer först, och sedan B. ? efter ett element betyder att det kan utelämnas, + betyder att den skall vara med en eller flera gånger och * betyder att det kan utelämnas eller inkluderas en eller flera gånger. (* är på sätt och vis detsamma som + och ? kombinerat.) #PCDATA står för vanlig text (något förenklat).
En viktig skillnad mellan XML och SGML är att elementen i XML som inte har innehåll (som t.ex. IMG eller BR i HTML) skall skrivas så här i XML:
<IMG SRC="pamela.gif"/>. Märk bråkstrecket före den avslutande >'en. Detta gör att ett program som läser dokumentet utan att känna DTD'n vet att detta element inte har något innehåll, så att det inte behöver att leta efter en slut-tagg och att den vet att det som kommer efter taggen inte är inuti elementet.
<!ATTLIST> används till att ange vilka attribut som ett element kan ha. I DTD-en ovan användes de till att tala om att elementen PART och Q har et attribut som heter NO, som innehåller vanlig text och som kan utelämnas. Som du ser har PART två attribut, det sista heter TITLE och innehåller text som kan utelämnas.
HyTime är en standard som (bland annat) anger hur länkar mellan skilda SGML-dokumenter kan göras. Den är mycket mer avancerad än länkning i HTML och innehåller mycket som man inte har användning för på webben. XWG håller därför på att skapa en standard for XML som lånar mycket från HyTime (och liknande standarder), men i förenklad form.
För att man skall kunna använda denna länkstandard i vilken som helst DTD har man inte definierat några egna element för detta. I stället är det vanligt att länkande element använder ett eget attribut som identifierar dem som länkar. Alla element som har ett attribut XML-LINK kommer att tolkas som en länk. Värdet på XML-LINK anger vad för slags länk det rör sig om.
Länkar i XML kan förbinda två eller flera resurser där resurser kan vara antingen filer (och inte nödvändigtvis XML eller HTML-filer) eller element i filer. Länkar kan sättes upp med hjälp av ACTUATE-attributet på så sätt att de antingen utförs när användaren ber om det (genom att klicka eller på annat sätt, värde=USER) eller automatiskt (dvs. när systemet läser det länkande elementet, värde=AUTO). Vad som sker när man följer en link i XML anges med SHOW-attributet, som kan ha följande värden:
XML har också mer avancerade länkar än detta. Länkar kan gå till mer än en resurs, länkar kan anges utanför dokumenten de länkar samman och vilket element i en resurs en länk går till kan anges på mycket avancerat sätt. Elementen kan identifieras med ett ID-attribut, position i element-strukturen och man kan till och med ange saker som att länken skall gå till "fjärde LI-elementet i tredje UL-element inuti BODY-elementet".
I FAQML kunde detta ha använts både för att ange länkar från dokumentet till relevant information utanför och till att länka samman olika svar. Fotnoter kan också anges på detta vis.
Också här finns det redan en SGML-standard, som heter DSSSL (uttalas dissel), och även den är inte helt enkel att använda. Följaktligen har XWG också här bestämt sig för att skapa en förenklad version som de kallar XSL. Man arbetar på ett förslag (se referens) men då det fortfarande är oklart om det blir accepterat, så tänker jag beskriva DSSSL i stället.
DSSSL är faktiskt ett programmeringsspråk baserat på Scheme (en dialekt av LISP,) och ger avancerade möjligheter att påverka ett SGML-dokumentet. Om man vill kan man använda det som en enkel stilmall som anger typsnitt och stil för de olika elementen. Eftersom DSSSL är baserat på Scheme kan man dessutom enkelt utvidga detta till kraftigare saker.
DSSSL används som regel till att konvertera SGML dokument till ett format som är bättre lämpat för presentation, till exempel PDF (Portable Document Format, kanske mer känt som Acrobat), PostScript, LaTeX, HTML eller RTF (Microsoft Rich Text Format). XWG vill använda XSL för att specificera hur XML dokument skall presenteras på en skärm.
Nedan skall jag försöka att visa hur man kan skapa en stilmall för FAQML, men utan att gå in på detaljer. Jag har delat in filen i delar för att lätt kunna skjuta in förklaringar, men det är alltså tal om en sammenhängande fil.
DSSSL består av flera delar, där den grundläggande är uttrycks-språket som helt enkelt är hämtat från Scheme. Detta gör att alla DSSSL-stilmallar egentligen är ett stort Scheme-uttryck som beräknas av DSSSL-motorn och ger en eller annan fil som resultat. En annen viktig del är stil-språket (som bygger på uttrycks-språket), som jag använt nästan uteslutande i detta exempel. En tredje del är ett sök-språk som kan användas till att finna de elementen man är ute efter i en SGML-fil. Jag har använt det nedan för att finna numret på en FAQ-fråga inne i QTEXT-elementet.
All formatering i DSSSL görs med så kallade flödesobjekt, och nedan ser man en mängd uttryck av typen (element X (make Y som anger att när element X dyker upp skall ett flödesobjekt av typ Y skapas. Därefter specificeras stilregler för Y och till slut innehållet i Y. Det finns mycket mer att säga om DSSSL än detta, men det ligger utanför detta dokument.
<!doctype style-sheet PUBLIC "-//James Clark//DTD DSSSL Style Sheet//EN"> ;--- DSSSL stilmall för FAQML ;---Konstanter (define *font-size* 12pt) (define *font* "Times New Roman")
Den första raden anger bara att det följande dokumentet följer SGML-DTD'n för DSSSL. De två följande raderna är kommentarer (efter ett semikolon ; blir resten av linjen ignorerad). Sedan definerar jag två konstanter som kommer att användas längre ned i stilmallarna. Tanken med detta är att om jag plötsligt skulle få lust till att göra all skriften i dokumentet lite större så behöver jag bara ändra *font-str* till 13 och slipper gå igenom hela filen.
;---Element styles (element FAQ (make simple-page-sequence font-family-name: *font* font-size: *font-size* input-whitespace-treatment: 'collapse line-spacing: (* *font-size* 1.2) (process-children)))
Denna delen skapar ett flödes objekt för FAQ elementet, dvs hela dokumentet. Flödes objektet är ett "simple-page-sequence", vilket antas gälla för små artiklar. Därefter specificerar jag vilket typsnitt, storlek, att whitespace (dvs mellanrum, tabbar och nyrad) är utan betydelse (liksom i HTML) och sedan anger jag radavståndet. Radavståndet sätts till 1.2 gånger typsnittets storlek . process-children betyder att också alla element inuti FAQ-elementet skall behandles med dessa värden.
(element INFO (make paragraph quadding: 'center space-after: (* *font-size* 1.5) (process-children)))
Detta anger att elementet INFO (från start-tagg till slut-tagg) skall skapas som ett avsnitt (paragraf) som skall vara centrerat och ha ett mellanrum på 1.5 gånger typsnittets storlek efter sig. Därefter behandlas barnen (dvs elementen inuti i INFO).
(element SUBJECT (make paragraph font-size: (* *font-size* 2) line-spacing: (* *font-size* 2) space-after: (* *font-size* 2) (process-children)))
SUBJECT-elementet får ett eget avsnitt och skall visas i dubbel skriftstorlek. AUTHOR och EMAIL är förenklade versioner av detta, så jag hoppar över dem. (De ingår naturligtvis i den kompletta DSSSL filen nedan.)
(element VERSION (make paragraph (make sequence (literal "Version: ")) (process-children)))
VERSION-elementet får ett eget avsnitt som innehåller sekvens-flödesobjekt. Jag infogar ett som innehåller text-konstanten "Version:" innan själva innehållet av VERSION-elementet behandlats. Resultatet är alltså att texten-strängen "Version:" kommer att infogas före versionsnumret i avsnittet som skapas. DATE-elementet är liknande, så jag hoppar over det.
(element PART (make paragraph font-size: (* *font-size* 1.5) line-spacing: (* *font-size* 2) (make sequence (literal (attribute-string "NO" (current-node))) (literal ". ") (literal (attribute-string "TITLE" (current-node))) ) (process-children)))
Jag vill att PART skall visas med stor text, med nummer och titel, som t.ex.: "1. Grundläggande XML". Vi använder därför precis som i VERSION-elementet ovan ett sekvens-flödesobjekt - men hur får vi reda på numret och titeln? De existerar som attribut och med hjälp av funktionen attribute-string kan jag ta reda på dessa värden: (attribute-string "NO" (current-node)) ger mig värdet på attributet NO i det aktuella elementet. Sedan infogar vi ". " efter NO och därefter kommer titeln till slut. Den återstående delen av stilmallen är så enkel att den hoppar jag över.
Om någon är intresserad så har jag lagt ut den fullständiga DSSSL-filen här, tillsammans med resultatet i RTF- och PostScript-format. RTF-filen är skapad med Jade (se referens 12) och PostScript-filen är skapad utifrån denna).
För tillfället ser det inte ut som om XSL kommer att baseras på Scheme, eftersom Netscape, Microsoft och andra redan har stöd för ett skriptspråk, JavaScript, i sina webbläsare. Därmed verkar det troligt att XSL kommer att definieras som en XML-DTD som använder JavaScript för programmering. Det är synd då DSSSL har en så bra syntax och Scheme är ett mycket bra programmeringsspråk. (JavaScript är för övrigt också ett mindre kraftfullt språk än Scheme.)
Var klar över att det följande endast är mina personliga åsikter om WWWs framtid så att allt bör tas med en nypa salt. (Referens 4 är en ypperlig artikel av XWGs ordförande Jon Bosak om XML och webbens framtid.)
Det fösta jag hoppas XML kan rätta till är problemet med att skapa webbsidor med anständig layout som är läslig av alla. I och med att XSL kommer att vara en fullständig standard som stöds av alla bör man snart kunna räkna med att ha en fast stabil standard att följa. XSL tillåter också control av om ytterligare egenskaper finns med och om så är fallet kan man erbjuda alternativ kod för att även täcka dessa fall.
Den som är ansvarig för en FAQ kommer också att slippa problemet med att upprätthålla FAQ'n som HTML, .txt och PDF-version. I stället kan han/hon skapa en (eller flera) DSSSL-stilmallar som körs varje gång XML-originalet uppdateras och automatiskt uppdaterar filer i de andra formaten. (Precis som jag producerade .RTF och .PS-filer från min FAQ ovan.)
I och med att varken Microsoft eller Netscape har klarat av att korrekt implementera CSS (eller ens HTML) måste man undra hur det skall gå när de skall pröva sig på att implementera XML och XSL. Jag hoppas att de förstår att de är tvungna att verkligen anstränga sig och skriva om webbläsarna från grunden, för om de inte gör det så kommer någon annan att se sin chans att ta över marknaden. De har nu lovat att stötta XML, så det finns grund till hopp, men inte mer... (Se referens 5 och 6.)
Ett API (Application Programming Interface) för XML och HTML som alla XML/HTML-processorer (dvs webbläsarna och andre verktyg) kan/bör stötta (kallat Document Object Model, eller DOM) är under utarbetning. Det föregår lite vid sidan av XWGs arbete, men är likväl på god väg. (Se referens 7.) Detta API gör det möjligt att skapa Java-applets (eller återanvändbara JavaScript-koder, s.k. JavaScriptlets ) som kan användas till att påverka visningen av den XML-kodade informationen i webbläsarna. (Medlemmarna i XWG brukar kalla detta "giving Java something to work with".)
Detta kan användas på i det närmaste oändligt många sätt, men exempel på det som utvecklarna tänkt sig är fotnoter som inte syns förän du trycker på fotnot-hänvisningen (t.ex. numret) i den löpande texten, att man kan få upp bara kapitelöverskrifter i ett stort dokument och så klicka på ett kapitel för att få underkapitelöverskrifterna i ett (eller alla) kapitel och så klicka på underkapitelet för att få se innehållet. Man kan också skapa saker som tabeller som man kan ändra sorteringen på med en klick på kolonnen man vill ha sorterad. Möjligheterna är som sagt otaliga och detta är bara toppen av isberget.
Detta kan göras väsentligt mer avancerat. Till exempel kan VRML (Virtual Reality Modeling Language, språk för kodning av tre-dimensionella världar) omdefinieras som ett XML-språk och VRML-visare kan göras som en Java-applet som använder DOM. (Om du tror detta är science fiction så ta en titt på referens 8.) Detta betyder att man kan använda VRML, som det ursprungligen var tänkt, tillsammans med HTML men utan att behöva någon annan programvara än webbläsaren själv. (Och Java-appleten, men de "installerer" sig ju själva.)
Jon Bosak beskriver i referens 4 en ännu mer avancerad möjlighet. De största producenterna av integrerade kretsar (s.k. chips) har gått samman om att skapa en DTD som kan användas till att beskriva komponenter. Sammen med någon Java applet kan man använda detta till att ladda ned beskrivningar på olika kretser och sedan modellera hur de fungerar tillsammeans.
Tillämpningarna som beskrivs här är inte realiserbara nu men jag hoppas att de kommer att bli inom en inte alltför avlägsen framtid.
Att informationen i XML-dokument beskrivs så exakt av markeringarna gör att man kan söka på helt andra sätt än de primitiva text-sökrutinerna som sökmotorer som Excite och Altavista använder idag. Det finns redan SGML-sökspråk som har funktionalitet som påminner om SQL (Search-Query-Language) och det forskas en hel del på detta. (Se referens 9 och 10.)
Med standardiserade DTDer för olika tillämpningar skulle man kunna leta reda på information med mycket högre träffsäkerhet än vad som är möjligt i dag. Man kan föreställa sig saker som en central söktjänst för chiptillverkare som bygger på DTDen jag pratade om tidigare och tillåter sökning i kretsbeskrivningarna till många olika fabrikanter. Därmed skulle man kunna göra mycket exakta sökningar på kretser efter specifikationer, nästan som om man hade en vanlig relationsdatabas. Liknande service vore möjlig för alla dokument med en gemensam DTD.
Att utnyttja detta för globala söktjänster som Excite och Altavista kommer att vara mycket svårare beroende på det stora antalet olika DTDer som kommer att finnas. Med en översikt över de viktigaste DTDerna och lite artificiell intelligens i sökverktygen så skulle det kanske kunna hanteras, men för ögonblicket är det ren science fiction.
Jon Bosak talar om att utnyttja denna teknik tillsammans med intelligenta agenter, som är personliga webbrobotar som rusar runt på nätet och letar efter information till dig personligen enligt dina inställningar. Detta har antagligen större chanser att lyckas, eftersom du i dina inställningar skulle kunna begränsa listan av möjliga DTDer och därmed skulle säkert den artificiella intelligens-biten bli enklare, men det är ändå bara en framtidsvision.
Eftersom en DTD anger ett standardformat för information inom ett bestämt användningsområde underlättar detta informationsutbytet mellan olika parter. Många typer av tillämpningar har eller kommer att ha standardiserade DTDer. Jag har redan nämt chiptillverkarna, och många andra industrigrenar har redan standardiserade DTDer och fler kommer att följa. Detta betyder att system kan använda dessa standardiserade DTDer för att utbyta information med varandra. Detta gör att data lätt kan flyttas från en databas till en annan, oberoende av vilket system dessa databaser faktisk utnyttjar sig av internt. Det huvudsakliga användningsområdet kommer antagligen att vara utbyte av data mellan företag inom samma industrigren eller mellan forskare inom en akademisk disciplin, även om många andra användningsområden för vanliga användare kan tänkas.
Det har till exempel redan utvecklats ett eget XML-språk for kemister, kallat CML. (Se referens 11.) Detta kommer att vara mycket aktuellt för utbyte av data mellan kemister och företag som arbetar med kemi på ett eller annat sätt. Det kan också användas tillsammans med Java-applets i undervisning. Möjigheterna är helt enkelt svindlande.