För att kunna besvara den problemformulering jag ställt, måste en förståelse för hur XML är uppbyggt fås. Detta sker genom en studie av XML:s syntax. W3C släppte rekommendationen till ”XML 1.0” den 10 februari 1998 och den återfinns i sin helhet på http://www.w3.org/TR/REC-xml. Utvecklingen gick snabbt och man kompromissade hårt inte minst för att göra XML lättare att förstå än föregångaren SGML.
W3C satte upp tio mål för utvecklingsarbetet av XML-specifikationen:
• XML ska vara lätt att använda över Internet.
• XML ska kunna användas till många olika områden.
• XML ska vara kompatibelt med SGML.
• Det ska vara lätt att skriva program som använder sig av XML.
• Antalet valfria finesser ska hållas till ett minimum, helst noll.
• XML-dokument ska vara läsbara med en vanlig texteditor och dessutom vara lättlästa.
• Standarden ska fastslås fort.
• XML-specifikationen ska vara formell och kortfattad.
• Det ska vara enkelt att skapa XML-dokument.
• Det finns inget krav på att XML-dokumentet i sig självt, ska vara kortfattat.
Länkar och presentation lades utanför XML från början. Andra tillägg kom senare. De flesta tillägg är så kallade "applikationer" på XML, det vill säga uppmärkningsspråk som använder reglerna i XML som bas.
Efter två år är nu utvecklingen av de standarder som började utvecklas i samband med XML snart färdiga. Utvecklingen har tagit oanade vändningar och nya smarta webbstandarder är på väg som ger mervärde åt XML som filformat. Snart kommer vi att få se webbläsare och andra programvaror som hanterar inte bara XML, utan också stilmallar och länkning (XML Sweden 2000).
Anledningen till att jag lade syntaxstudien i genomförande, istället för att lägga den i den teoretiska referensramen, var att jag ville att läsaren skulle få problemställningen presenterad för sig innan syntaxen gicks igenom. Genom att ha problemställningen beskriven när syntaxen gås igenom, kan läsaren lättare få en insikt i XML:s positiva och negativa sidor vad det gäller rollen som meddelandeformat inom området elektroniska transaktioner.
5.1.1 Teckenuppsättningar och lagringsformat
För att åstadkomma ett plattformsoberoende och applikationsoberoende måste tecknen som överförs tolkas på samma sätt överallt. HTML- och SGML-dokument använder ASCII10-teckenuppsättning som är en av de mest använda koderna för att representera tecken. Koderna består av sju bitar vilket medför att 128 olika tecken kan representeras (den åttonde biten har använts som kontrollbit). XML använder istället ISO-standarden ISO 10646 vilken består av 32 bitar, detta medför att alla tecken i hela världen går att representera. Det finns komprimerade scheman av ISO 10646 som medför ett variabelt antal bitar. Det är ju slöseri att överföra 32 bitar när den teckenuppsättning man använder, klarar sig med 128 tecken, dvs. 7 bitar. XML har stöd för två av dessa scheman UTF-8 och UTF-16. UTF-8 är den teckenuppsättning som används om inte någon annan specificeras i XML-deklarationen.
En XML-fil är en enkel textfil vilket innebär att den inte innehåller några formateringstecken utan bara är oformaterade tecken. En XML-fil kan därför editeras utan speciell XML-programvara, det går bra med en enkel texteditor som t.ex.
”Anteckningar” i Windows eller Emacs. Filen sparas sedan ner som text med filändelsen ”.xml”.
En viktig sak att tänka på när en XML-fil editeras, är att XML skiljer på gemener och versaler.
5.1.2 Ett dokuments uppbyggnad
XML är stamfadern i XML-familjen. XML är två saker:
• Dels är XML en specifikation på hur man beskriver nya uppmärkningsspråk.
En sådan beskrivning av ett språk, formulerad enligt en viss syntax, kallas dokument typs definition (DTD). Varje DTD sägs vara en applikation av XML, för ett visst syfte (webbsidor, orderdokument, kundregister och så vidare).
• Dels specificerar XML en gemensam syntax för dessa språk, så att de kan kontrolleras av samma mjukvara. Alla uppmärkningspråk som är skapade utifrån XML behandlas som en särskild filtyp, vars kännetecken är en lättförståelig, självbeskrivande syntax som skiljer struktur och sakinnehåll från presentation (XML Sweden 2000).
Ett XML-dokument beskriver bara innehåll och struktur, hur detta sedan ska presenteras lämnas över till en layoutmall som anropas från XML-dokumentet. En uppdelning utefter struktur, data och layout, medför att det sätt på vilket innehållet presenteras kan ske utifrån samma XML-dokument men med olika formatmallar.
Detta ger en flexibilitet och en återanvändning av informationen. Om ett företag har en produktkatalog som är skriven i XML, kan företaget skapa olika layoutmallar för presentation av katalogen. Som exempel kan ges, att om det t.ex. är en registrerad återförsäljare kan denne även få priserna utsatta, medan en annan kund endast får se en del av informationen, t.ex. en beskrivande text samt bilder på produkterna.
10American Standard Code for Information Interchange.
Ett XML-dokument består av ett innehåll och en uppmärkning av innehållet. För uppmärkning av innehållet används märkord. Märkorden ska beskriva vad innehållet representerar för typ av information. Det är alltså upp till utvecklaren att avgöra vilka namn han/hon sätter på märkorden.
Ett XML-dokument kan se ut på följande sätt:
<?xml version=”1.0”?>
Ett XML-dokument kan delas in i tre sektioner, prolog, root och epilog. Prologen är deklarationen för dokumentet. Mittensektionen har ett root-element som beskriver vad det hela är för ett dokument. I epilogen kan kommentarer och dylikt infogas.
Prolog
Första raden <?xml version=”1.0”?> är en deklaration som säger att följande dokument är ett XML-dokument och vilken version av XML som används. Här kan man också deklarera om något eller några andra dokument är kopplade till detta dokument, t.ex. en Dokument Typs Definition (DTD) eller om dokumentet kan hanteras självständigt, mer om denna senare. I deklarationen kan också anges vilken teckenuppsättning som används, om inget anges används UTF-8. XML deklarationen identifieras av att den inleds och avslutas med ett ”?”.
Root
Dokumentet innehåller ett rootelement i det här fallet ”order”. Rootelementet ska omsluta alla andra element och följaktligen stängs det med </order>. Märkordet tillsammans med innehåll kallas för element. <stad>Stockholm</stad> är alltså ett element med namnet ”stad” och innehållet ”Stockholm”.
Attribut innebär en möjlighet att tilldela egenskaper för ett element. Egenskaperna tilldelas alltid i märkordets starttag, <styckpris valuta=”SEK”> anger att priset anges i svenska kronor.
Epilog
Kommentering kan ske, <!--Skapat av Mathias--> är en sådan. Kommentarer inleds med <!-- och avslutas med -->.
5.1.3 Dokument Typs Definition (DTD)
För att t.ex. två informationssystem ska kunna överföra data mellan sig och tolka denna på rätt sätt, krävs det att bägge förstår precis vilken form av data det är som överförs. Därför måste det till en i förväg definierad dokumentstruktur. Denna beskriver vad som får finnas med och inte får finnas med i dokumentet, vissa element måste finnas med andra är frivilliga. ”XML 1.0” innehåller syntax för att beskriva mallar. Dessa mallar kallas DTD:er.
En DTD beskriver en modell av innehållets struktur i ett XML-dokument. Den innehåller regler för hur informationen är strukturerad. DTD:n talar om:
• vilka element som förekommer i informationen
• hur dessa element får förekomma och ingå i varandra
• vilka attribut som finns till varje element
En DTD kan ses som en upp- och nervänd trädstruktur. Om vi fortsätter med order exemplet:
o r d e r n r
n a m n g a tu a d r e ss sta d
k u n d
a r tik e ln r b e sk r ivn in g a n ta l sty c k p r is o r d e r r a d
O r d e r
Figur 1 Trädstruktur
En DTD skrivs för varje typ av dokument t.ex. order, faktura, patientjournal etc. Hur denna ska se ut är upp till utvecklaren att styra. En DTD kan antingen vara intern eller extern. En intern DTD bakas in i det XML-dokument den ska definiera och en extern DTD anropas från XML-dokumentet. Det normala och mest flexibla sättet är att använda sig av externa DTD:er. Fördelen med detta är att om flera XML-dokument använder sig av samma DTD och ändringar behöver göras, justeras detta på en plats istället för att ändra i varje XML-dokument.
Hur ser då en DTD ut? Vi skapar ”order.dtd”.
<!DOCTYPE order[
<!ELEMENT order(ordernr, kund, orderrad+)>
<!ELEMENT ordernr(#PCDATA)>
<!ELEMENT kund(namn, gatuadress, stad)>
<!ELEMENT namn(#PCDATA)>
<!ELEMENT gatuadress(#PCDATA)>
<!ELEMENT stad(#PCDATA)>
<!ELEMENT orderrad(artikelnr, beskrivning?, antal, pris)>
<!ELEMENT artikelnr(#PCDATA)>
<!ELEMENT beskrivning(#PCDATA)>
<!ELEMENT antal(#PCDATA)>
<!ELEMENT styckpris(#PCDATA)>
<!ATTLIST styckpris
styckpris(SEK|NKR|EUR)>
]>
För att använda ovanstående DTD i vår order.xml fil, måste vi lägga till en rad, först i XML-dokumentet, nämligen:
<!DOCTYPE order PUBLIC http://www.adress.com/order.dtd>
När sedan DTD:n anropas byts ovanstående rad ut mot vår order.dtd i XML-dokumentet. Ett XML-dokument kan sägas vara ”well-formed” om det är helt syntaktisk korrekt. Följer det dessutom en angiven DTD, sägs det vara ”valid”. Att ett dokument är ”valid” innebär då följaktligen att det också är ”well-formed”. På detta sätt går det att kontrollera om dokumenten överensstämmer med mallarna.
DTD:n beskriver alltså vad det är för information som får finnas med i XML-dokumentet. I DTD:n ovan kan utläsas att dokumenttypen ”order” måste innehålla elementen ordernr, kund och orderrad. Dessa element måste förekomma i nämnd ordning. Ordernr och kund får bara förekomma en gång i dokumentet, orderrad åtföljs av ett plustecken, detta indikerar att orderrad får förekomma en eller flera gånger (1:M) i XML-dokumentet. De möjligheter som ges för att ange antalsvillkor är ”+”,
”?” och ”*”, vilka står för i nämnd ordning, en till många (1:M), noll eller en gång (0:1) och noll eller många gånger (0:M).
Alla löv-element är deklarerade som #PCDATA, vilket står för Parsed Character Data, det vill säga text som kan identifieras. Detta för att möjligheten att deklarera egna datatyper inte finns i XML än så länge. Utöver PCDATA finns det några fler fördefinierade datatyper däribland EMPTY, vilket innebär att elementet deklareras som tomt. Detta görs t.ex. för bilder, då elementet får vara tomt, men det förses med ett attribut, då lämpligen adressen till bilden som ska infogas.
Till elementet styckpris har vi kopplat ett attribut, valuta i vilket priset anges. I vårt fall kan det vara antingen svenska eller norska kronor eller euro.
På grund av de begränsningar som finns med DTD:er har W3C flera förslag på att utöka funktionaliteten hos DTD:er som med sitt ursprung hos SGML blivit för trubbiga för dagens tillämpningar. För att göra det möjligt att automatisera vissa processer på webben idag, krävs det en större kontroll på dokumentens innehåll än vad DTD:er erbjuder. XML Schema ("scheman") ger framförallt mer kontroll över elementinnehåll och datatyper, samt möjliggör större flexibilitet. Dessutom använder scheman XML:s egen syntax för att föreskriva en dokumenttyps grammatik (XML Sweden 2000). XML Schema ligger förnärvarande som ”Working draft”11 men kommer troligen som rekommendation under den närmaste tiden, utkast finns att läsa på http://www.w3.org/TR/xmlschema-2/.
5.1.4 Namespaces
Namespaces ("namnrymder") är den enda egentliga utbyggnaden av XML-syntaxen.
Namnrymder gör det möjligt att identifiera och särskilja varje innebörd av ett element så att beståndsdelar från flera olika DTD:er kan användas tillsammans utan risk för semantiska konflikter. Att unikt kunna identifiera ett element och förhindra namnkrockar när man t.ex. importerar ett färdigt dokument in i sitt XML-dokument.
Ett exempel på en sådan konflikt är det vanliga ordet "titel", som kan betyda såväl boktitel som yrkestitel. Utanför ursprungsdokumentet riskerar <titel> att blandas ihop med andra element med samma namn, men med en annan innebörd. Genom ett prefix (till exempel <person:titel>) ger man elementet en universiell betydelse.
Principen för namnrymder är inte helt okontroversiell, men trots det används den av i snart sagt alla viktiga applikationer inom XML-familjen (XML Sweden 2000).
Hela rekommendationen finns tillgänglig på http://www.w3.org/TR/REC-xml-names/.
5.1.5 Presentation
I själva XML-dokumentet finns ingen information om hur innehållet ska presenteras, information om layout finns istället lagrat i en separat fil, en så kallad layoutmall (stylesheet). Detta är som jag tidigare nämnt en stor fördel då samma XML-dokument kan anropa olika mallar beroende på var och hur informationen ska presenteras.
W3C:s rekommendation för layoutmallar kallas XSL12 och finns i sin helhet här : http://www.w3.org/TR/xsl/ och har varit under utveckling allt sedan XML kom till.
Layoutreglerna i XSL skrivs enligt XML-syntax, vilket leder till att en layoutmall kodad enligt XSL, är ett XML-dokument. XSL är stort, vilket gör det relativt svårt att lära och implementera. Detta har lett till att ett alternativ Cascading Style Sheets (CSS) använts, men detta är egentligen utvecklat för HTML. Mer om CSS nivå två, specifikation återfinns på http://www.w3.org/TR/REC-CSS2.
XSL kan också användas för att transformera informationen från ett format till ett annat, denna rekommendation från W3C kallas XSLT13. Används t.ex. för att transformera ett XML-dokument till HTML.
11 Working Draft, ett utkast från W3C som ännu inte gått från utkast till rekommendation.
Rekommendation under arbete.
12eXstensible Stylesheet Language
13XSL Transformations
5.1.6 Länkning
Länkar är ju av väldigt central betydelse för att söka sig fram till olika informationsresurser på WWW. W3C håller på och tar fram en ny länkstandard XLL14 som är tänkt att användas tillsammans med XML. Det är egentligen en paraplyterm för två separata standarder som heter Xlink och Xpointer, återfinns i sin helhet på http://www.w3.org/TR/xlink/ och http://www.w3.org/TR/xptr. Lite förenklat skulle detta kunna beskrivas så att Xlink pekar ut en resurs och Xpointer pekar ut något inne i en resurs. Med Xlink går det att skapa simple och extended links, där simple liknar HTML:s <a href=”sida.html”>Sidan</a>, alltså en vanlig hypertextlänk som används på WWW. Men det går också att länka flervärt, ange relationer mellan två eller flera resurser, så att en länk för t.ex. nedladdning av en fil kan ske från flera olika valbara källor i samma länk, detta kallas extended. En simple länk skulle i XML kunna se ut på följande sätt:
<sidan xlink:form=”simple”
href=”www.sidan.com”>Sidan</sidan>
I XML kan länkning ske från alla element och inte som i HTML, bara genom ett <a>-element.
Xpointer kan peka på ett visst element inuti ett dokument, detta kan på sätt och vis göras med HTML (peka på en plats i dokumentet) men då måste tillgång finnas till måldokumentets källkod för att göra de justeringar som behövs där, detta behövs alltså inte med Xpointer. Länkning med hjälp av Xpointer kan peka ut särskilda områden eller spännvidder av ett dokument, detta för att det t.ex. ska användas för att laddas in i en programvara för vidare behandling. En annan fördel är att det är möjligt att skilja länkarna från det dokument de länkar till/från genom att lägga länkarna i separata filer eller länkdatabaser vilket gör uppdateringar smidigare.
5.1.7 Allmänt
Det finns runt 20 rekommendationer och så kallade arbetsutkast hos W3C i dagsläget.
Att ta upp alla här tror jag skulle förvilla mer än de skulle hjälpa till, för att få en grundläggande förståelse för XML.
Därför har tyngdpunkten lagts på de intressantaste och mest användbara områdena inom XML-familjen.
14eXstensible Linking Language
5.2 Intervjuer
För att få en så bred bild av området elektronisk handel – XML som möjligt, ville jag göra intervjuer med olika typer av företag så som:
• XML-specialister, företag som inriktat sin verksamhet mot XML
• traditionella IT-konsulter (t.ex. WM-data)
• storföretag (t.ex. Volvo)
Intervjuernas tyngdpunkt lades mot de frågeställningar och funderingar jag tog upp i min problembeskrivning. Besöksintervjuer genomfördes på Cap Geminis kontor i Jönköping och vid Volvo lastvagnars kontor i Skövde. Resterande intervjuer genomfördes som telefonintervjuer på grund av det långa avståndet till intervjupersonerna. Intervjun vid Volvo visade sig resultera i ett namn och telefonnummer till en person på IT-avdelningen i Göteborg, då de i Skövde inte hade någon som helst kännedom om XML.
Eftersom det område jag valt att undersöka är väldigt nytt har det visat sig svårt att finna personer som besitter kompetens inom både elektronisk handel och XML.
5.2.1 XML-specialister
Här valde jag att intervjua två spetsföretag som inriktat sig mot XML, de två var Improve15 och Avantra16.
Avantra
På Avantra genomfördes en telefonintervju med en man som jobbade som koncept-utvecklare vid Luleå kontoret. Avantra hade inte någon färdig installation, men de hade tagit fram en specifikation på ett projekt där 22 företag ingick. Bedömningen från Avantras sida var att XML kommer på bred front och då överallt där informationsöverföring är aktuell. Problemen låg inte i standarden utan mera som i vanliga utvecklingsprojekt, det var många frågor att reda ut mellan verksamheterna.
En del företag hade uppfattningen att XML löser alla världens problem, medan andra var försiktigare och funderade över affärsnyttan med att gå över till XML.
Avantra tillfrågades om de hellre såg att W3C stabiliserade standarden istället för att hela tiden komma med nya utkast från de många tillsatta arbetsgrupperna, Avantra svarade att W3C måste hålla ett högt tempo. Detta för att inte hamna i samma situation som med HTML, nämligen den att företagen gör egna tolkningar och hittar på egna lösningar, specifika för det företagets produkter. Detta var fallet mellan Microsofts webbläsare ”Internet Explorer” och Netscapes, ”Navigator”. Webbsidorna såg inte likadana ut i de två programmen, vilket ju är hela vitsen med att använda sig av standarder.
Kontentan av det hela blir att om inte W3C kommer upp med en lösning så gör företagen det själva och då försvinner vitsen med en samlad rekommendation.
15Improve, URL (http://www.improve.com)
16Avantra, URL (http://www.avantra.se)
Avantra menade också att de som sitter och arbetar med XML-frågorna, i mångt och mycket är samma folk som var med att ta fram både SGML och HTML. Detta borgar för att de är insatta i problematiken menar Avantra.
På mina frågor kring problemen med avsaknaden av en gemensam begreppsapparat, egentligen en samlad uppslutning kring modellering och namnsättning, fick jag svaret att det givetvis var ett dilemma. Samtidigt ansågs att någonstans måste det hela börja, för att en utveckling ska ske. Det kommer att utkristallisera sig lösningar allt eftersom utveckling sker, trodde man.
Jag ställde frågan att om det var så att någon ytterligare part skulle in i det projekt Avantra hade tagit fram en specifikation på och denne någon redan hade en sfär med parter runt sig. Dessa parter hade också gått samman och enats kring ett ramverk som troligtvis inte var det samma som det Avantra specificerat, vad sker då?
Det var ett problem, men vid en avvägning mot att inte börja alls, framstod det som ett naturligt steg att dra igång projektet. Tre scenarier kunde ses: nya affärsparter fick antingen integreras genom att uppsluta kring specifikationen, eller att skriva en helt ny för de bägge sfärerna, eller att anpassa sig efter den nya sfären.
Avantra ansåg att den hierarkiska beskrivningen av verkligheten är en förutsättning för dokumentobjekt. Modelleringsbiten gick att komma runt genom att utnyttja XML:s länkmekanismer. Detta sågs inte som ett problem.
Improve
Improve är ett relativt nystartat företag som specialiserat sig inom XML, den person jag intervjuade hade erfarenhet från utveckling av olika konverteringsapplikationer från databaser till XML och vice versa.
På Improve hade ingen utveckling av applikationer inom området XML- elektronisk handel skett ännu. Men Improve såg det som något som kommer.
Att W3C hela tiden tar fram nya arbetsförslag, sågs på både gott och ont. Improve menade att det intressantaste med XML var just alla kringområden som gav XML mervärde. XML i sig är ganska tamt, enbart en ”platt”-fil, men tillsammans med t.ex.
XSL, XSLT, XML-schema och XLL blir det ett kraftfullt verktyg. Så det faktum att W3C höll ett högt tempo och kom med förslag till förbättringar var bra, men samtidigt
XSL, XSLT, XML-schema och XLL blir det ett kraftfullt verktyg. Så det faktum att W3C höll ett högt tempo och kom med förslag till förbättringar var bra, men samtidigt