Utlandsrapport. XML på den amerikanska scenen

Transkript

1 Utlandsrapport XML på den amerikanska scenen Nicklas Lundblad,Stig Berild, Nicklas Lundblad San Francisco,San Francisco November 1999

2 Innehåll 1 Inledning IT når varje hörn av vårt samhälle Med sikte på informationsutbyte Med sikte på informationssamverkan Fortsättning följer XML teknikperspektivet Dokumentinnehåll Dokumentmallar DTD-vokabulärer Att arbeta med ett mottaget dokument Presentation Språkkompletteringar Rikare referensmöjligheter Namespaces EDIFACT och XML. Vän eller fiende? XML i elektroniska affärer Inledning Visionen Dagsläget Initiativ på standardområdet en översikt Standarder? Vilka, för vad och av vem? AdXML BizTalk cxml CBL CPML ebxml eco FinXML FpML ICE Internet Open Trading Protocol Open Financial Exchange/Interactive Financial Exchange Open Buying on the Internet (OBI) P3P Utvecklingen Aktörer på XML-marknaden Arbortext Ariba Bluestone CommerceNet CommerceOne IBM Interleaf Microsoft OASIS Object Design Oracle... 46

3 5.12 Poet Software RosettaNet UWI WebMethods Händelseutvecklingen Affärscenario Några reflexioner Semantik Dokumentmetaforen Nyttjandebekymmer? Har W3C tappat fokus? XML för alla behov? Var finns det övergripande perspektivet? Avslutningsord Källor Sveriges Tekniska Attachéer Rapporten får inte kopieras utan tillstånd.

4 1 Inledning 1.1 IT når varje hörn av vårt samhälle Processorerna blir snabbare, minnena rymmer mer, kommunikationshastigheterna ökar allt i en rasande fart. Kontor och industrier fylls av stora och små datorer samt diverse kringutrustning. I många fall är de sammanbundna i nät. Internet-uppkoppling är snart en självklarhet. Mobiltelefoner, digitala assistenter (PDA), GPS-navigatorer, settop-boxar, m.m. blir allt intelligentare. Mobiltelefoner kompletteras med dator, datorer kompletteras med GPS, PDAer blir både dator, mobiltelefon och GPS,. gränserna suddas ut. Inom industri- och affärsverksamhet blir tillverknings-, affärs- och administrativa processer mer komplexa, löser mer avancerade uppgifter, blir alltmer integrerade och gränsöverskridande företagen emellan. Myndigheter och organisationer når ut med ett ständigt mer förfinat IT-baserat serviceutbud. Hemmen fylls med hemdatorer och avancerade dataspelsutrustningar. Bilar, tvättmaskiner, elmätare, TV-apparater och annan hemelektronik börjar fyllas med processorer för att informera, stödja, styra, övervaka. De fullgör alla var för sig med outsinlig ork sina arbetsuppgifter. I vissa fall sker det isolerat, i andra fall i samverkan över lokala nät (LAN) för mer sammansatta arbetsuppgifter. Både hem, industri, organisationer och förvaltning omfattas av en allt intensivare processamverkan. Information finns för alla dessa parter i outsinlig mängd, enkelt tillgänglig, fritt flödande mellan tillhandahållare och nyttjare över Internet, intranets och extranets. Avancerat informationsutbyte har blivit en självklar del i våra dagliga liv, både på jobbet och hemmavid. Information utgör dessutom ofta den formaliserade länken mellan samverkande parter i processer oavsett om dessa är människor eller IT-baserade. Vi talar här om informationssamverkan. I samband med XML kommer vi i denna rapport främst att behandla informationssamverkan. 1.2 Med sikte på informationsutbyte Med globala generella nät följer en helt ny dimension av samverkansmöjligheter, av möjligt tjänsteutbu samt informationsutbyte. Internet har banat väg. Öppenhet har blivit ett honnörsord. Men öppenhet ställer krav. Bilar är gjorda för att köras där det finns vägar, oavsett var dessa finns. Men det går knappast att köra utan trafikregler, åtminstone inte på ett ordnat, planerat sätt och i alla händelser inte när många samtidigt är ute och kör. De elektroniska näten kräver motsvarande umgängesregler i form av överenskomna protokoll och modeller. Med en strävan efter globala, allomfattande umgängesformer följer krav på regler som accepteras och tillämpas av alla. Acceptansen av TCP/IP-protokollen som nätverks- respektive transportprotokoll har banat väg för Internets, ja varit en förutsättning för dess framgång. Intranets kan visserligen tillämpa egna protokoll när så befinns vara

5 lämpligt men så fort behovet expanderar den minsta bit utanför de egna gränserna ökar behovet av öppenhet. Extranets existerar normalt i en öppen miljö med kontinuerligt skiftande förutsättningar i kontaktbehov och teknik. Standardprotokoll är nästintill ett måste såvida inte miljön är stabil och bygger på mycket speciella förutsättningar. Om och när vi når fram till ett allomfattande meganet för alla behov är ett enhetligt protokoll en underförstådd självklarhet. Med en globalt accepterad Internetstandard föddes visionen om en oändlig tillgång till information tillgänglig överallt och flödande genom näten. Men för detta krävs det mer än bara protokoll som hackar upp data i och för överföring och sedan binder ihop delarna igen på andra sidan. Information kan ha en sammansatt, formaliserad struktur. Inte minst gäller detta inom informationssamverkan. Delarna kan vara distribuerade till olika platser på nätet och information kan behöva relateras till annan information genom referenser(länkar). Informationen blir till en distribuerad hypertext, en väv av informationselement. World Wide Web (WWW) introducerades för ett tiotal år sedan i syfte att genom olika protokoll och modeller möjliggöra en enhetlig hantering av hypertexter över Internet. Med hjälp av Unified Resource Identifiers (URI) tänks såväl information som alla typer av abstrakta eller fysiska resurser i den elektroniska världen kunna identifieras. Inom Internet används vanligen en subtyp av URI benämnd Unified Resource Locator (URL). En URL identifierar en resurs genom att referera till dess absoluta plats. Protokollet Hypertext Transfer Protocol (HTTP) sköter kontakter och överföring. Klientdator Webbläsare Internet HTTP Webb Server Serverdator HTMLdokument Information kan alltså flöda. Men ska det vara någon vits med informationsflödet måste den som sänder och den som tar emot ha kommit överens om hur informationen ska vara strukturerad så att det avsändaren packar ner i en bitström inte bara kan återuppstå hos mottagaren efter uppackning utan även ge kompletterande information om struktur, layout, mm. I Internetvärlden grupperas och avgränsas en informationsmassa i form av en dokumentmetafor. Dokumentet har i allmänhet en mer eller mindre sammansatt intern struktur. Eftersom Hypertext Markup Language (HTML) tidigt anammades som generellt struktureringsspråk kunde avsändaren med hjälp av detta språk entydigt markera dokumentets delar, skicka över det till mottagaren, varefter mottagaren med samma kunskap om HTML och dess markeringar kunde generera dokumentet i det skick avsändaren avsett. I stort sett alla kommer till vardags i kontakt med Hypertext Markup Language (HTML). Dock utan att vi vet om det eller tar någon notis om det. Vartenda dokument som presenteras i våra webbläsare är nämligen strukturerat med hjälp av HTML inklusive tillkommande direktiv för dess presentation. Eftersom de allra flesta webbläsare förstår HTML och webbläsare finns i varje dator kan i stort alla världens dokument presenteras överallt. HTML

6 har förmodligen varit den viktigaste bidragande faktorn till webbens explosionsartade framväxt. HTML består av en fast uppsättning märkord som används för att identifiera dokuments typiska uppbyggnad i form av rubriker, stycken, tabeller, etc. HTML bekymrar sig däremot inte alls för innehållet i dessa dokument. <H1> Att åstadkomma datautbyte med hjälp av XML </H1> betyder lika mycket för en webbläsare som <H1> Bla bla bla </H1> Webbläsaren identifierar genom märkordet H1 texten som en rubrik på översta nivå, varken mer eller mindre. Vad rubriken betyder får läsaren själv genom sina kunskaper i svenska tolka efter eget huvud. Samma sak med övriga delar av dokumentet. HTML fungerar alldeles utmärkt vid många typer av enklare dokument, för sådant informationsutbyte vi vetgirigt blivit vana vid att initiera via våra webbläsare. 1.3 Med sikte på informationssamverkan Men informationsutbyte är inte vägs ände. I vissa fall räcker det inte med att skicka "några "standardlådor" med information. Vi behöver veta vad som är i "lådorna". Inte minst gäller detta i anslutning till informationssamverkan. Vi måste där kunna förmedla och ta emot dokument uppbyggda som mer eller mindre avancerade strukturer av informationselement. Strukturer har inte bara ett visuellt värde, de förmedlar kunskap om relationer mellan elementen och viktning dem emellan. Vi vill dessutom kunna komplettera med uppgift om varje ingående elements semantiska innebörd, allt för att förmedla ett ökat informationsinnehåll, underlätta tolkning och undvika missförstånd. En förutsättning för de elektroniska affärsprocesser som har att nyttja informationen. Genom det närmast exploderande intresset för e-commerce 1 ställs kraven på sin spets. Dokument skickas inte längre bara till människor för allmän läsning. De måste kunna skickas som viktiga informationsbärare i anslutning till alla de nya affärsprocesser inom e-commerce som snabbt ser dagens ljus, affärsprocesser som representerar en till synes oändlig uppfinningsrikedom. Dokument uppbyggda som semantiska elementstrukturer behöver, förutom att tolkas dessutom hanteras på olika mer eller mindre avancerade sätt, exempelvis delas upp, struktureras om eller sättas samman i nya dokumentstrukturer. Man brukar schablonmässigt tala om kategorierna Business-to-Consumer (B2C) där människor och företag utbyter information för något syfte och Business-to-Business (B2B) där företag sinsemellan utbyter information i och för fullgörandet av någon affärsprocess. Prognosinstitutet IDC räknar med att B2B e-commerce kommer att omsätta ca 500 miljarder dollar år 2002 eller ca fem gånger så mycket som B2C e-commerce. Lägger vi därtill all övrig samverkan som inte är direkt relaterad till köp och försäljning ser vi datautbytesvolymer av oanade mått. Följande schematiska exempel får illustrera B2B-utbyte: 1 Det finns ingen bra svensk översättning varför vi kommer att alternera mellan att använda det engelska ecommerce och det svenska elektroniska affärer.

7 Räkenskaper AB Firma Säljer Allt Fakturering Paket Ohoj upa Servicearkitektur Orderbehandling Citybanken Leverans Kreditkontroll Betalning En order (dokument) kommer in till Firma Säljer Allt. Den tas emot av Orderbehandling, en programmodul eller komponent hos firman som utför en avgränsad arbetsuppgift. Låt oss kalla det jobb. Orderbehandling utför för en typ av service. Firma Säljer Allt accepterar inte vilka kunder som helst. Därför skickas orderns kunduppgifter till Citybankens Kreditkontrollservice för bedömning. Svar lämnas till Orderbehandling som, om kunden visar sig vara trovärdig som kund, skickar ordern vidare till Paket Ohoj upa för leverans. Eftersom Firma Säljer Allt utlokaliserat all lagerhantering, paketering och distribution till Paket Ohoj upa är det lätt att inse att servicen Leverans omfattar en mängd arbetssteg involverande flera olika avdelningar inom företaget. Servicen Leverans är i det perspektivet att se som en egen fullödig, distribuerad affärsprocess. Nåväl, det sista Leverans gör är att meddela Orderbehandling att jobbet utförts så att Orderbehandling kan meddela Räkenskaper AB, det företag som sköter firmans ekonomi, att fakturering kan ske i enlighet med de uppgifter Leverans lämnat. Servicen Fakturering initieras. Eventuellt kan man tänka sig att Leverans har fullmakt att direkt meddela Fakturering detta utan inblandning av Orderbehandling. Även Fakturering är att se som en sammansatt affärsprocess med ett antal möjliga arbetssteg, inte minst i dialogen med den förhoppningsvis så småningom betalande kunden. Pengarna skickas till Citybanken där Betalning ser till att uppdatera aktuella konton, meddela Fakturering att betalning levererats samt Orderbehandling att de nu kan avsluta detta ärende. (Har Orderbehandling realiserats med objektorienterad teknik innebär det att den aktuella förekomsten av typen Orderbehandling utgår.) Som synes gäller här en samverkan mellan distribuerade, fristående servicefunktioner. En service ansvarar för och utför ett i sig fullständigt arbete från början till slut. Detta hindrar givetvis inte att servicen ingår som ett avgränsat steg i en än mer sammansatt process där varje steg och dess relatering till övriga steg är av avgörande betydelse för helhetsutfallet. Det intressanta är att man ofta kan acceptera en löslig bindning mellan de olika arbetsstegen både i utförandelogik och tid. När service A anropar service B väntar inte A tills B meddelar att dess arbete utförts så som är fallet för många traditionella, mer integrerade tillämpningar. A kan vid behov fortsätta med andra arbetsuppgifter däremellan. Inte heller spelar det så stor roll om det dröjer en stund innan den anropade servicen reagerar eller att anropet inte går fram direkt, t ex på grund av någon störning. Det får dröja av skäl man inte behöver bekymra sig om eller är beroende av. Man brukar skilja på synkron (integrerad, direkt beroende) och asynkron (lösligare, mer oberoende) samverkan. För e-commerce med sina behov av global och ofta spontant behovsrelaterad samverkan mellan fristående servicefunktioner passar asynkron samverkan ofta alldeles utmärkt. Vid asynkron samverkan är det dessutom alldeles naturligt att informationsutbytet sker i dokumentform. Med andra ord kan vårt exempel illustreras enligt figuren nedan

8 Räkenskaper AB Firma Säljer Allt Paket Ohoj upa Citybanken Lägg därtill alla övriga tillämpningar och aktiviteter som bygger på distribuerat, asynkront informationsutbyte företagen emellan eller mellan företag och människor i olika roller och i samverkan för något syfte. Servicetillhandahållare Affärspartner Egna Leverantörer intranet Internet extranet meganet Samhälle, Myndigheter Kunder Legacy + ERP Dessutom finns många olika behov av informationssamverkan människor emellan som man väljer att utföra asynkront för något syfte. Till sist tillkommer de behov av asynkron informationssamverkan som, parallellt med olika typer av processamverkan, i den annalkande post-pc-eran kommer att vara helt naturlig mellan i stort sett alla typer av processorbestyckade produkter, från Smart Cards, över mobiltelefoner till kraftfulla datorer. Smart Card Erbjuden service, inte dess fysiska förpackning, blir det intressanta. Liksom vikten av att betydelsen av den information som hanteras mellan de olika stegen i en sammansatt informationssamverkan inte missförstås. Vi måste alldeles uppenbart kunna precisera innehållet i dokumenten på ett entydigt och överenskommet sätt. Vem vill riskera

9 feltolkningar av fakturor, order, patientjournaler, arbetsscheman, produktspecifikationer, etc? Kanske är det inte alls aktuellt att presentera det i någon webbläsare för mänsklig tolkning. Kanske levereras istället dokumentet till någon tillämpning eller service som underlag för en bearbetning alternativt som svar från en sådan. Kanske förs dokumentets innehåll efter kontroll direkt in i en databas. Varje del av dokumentet måste med andra ord entydigt kunna avgränsas och förstås. Att förväxla 200 som beställt antal med 200 som à pris kan exempelvis få förödande konsekvenser. Problemställningen är knappast ny. I publiceringssammanhang identifierades behovet tidigt. Redan 1986 antogs en mycket ambitiös standard av ISO under benämningen Standard Generalized Markup Language (SGML). Se ISO Bekymret med SGML var att det var för omfattande, för ambitiöst - inte för sitt ursprungliga ändamål - avancerad publicering, utan för användning av "gemene man" i en universell webbmiljö befolkad av miljontals nyttjare. Webbens HTML saknade å sin sida uttrycksmedel för detta nya behov. Visserligen hade finurligt fixande och tänjande av HTMLs egenskaper delvis lyckats överbrygga en del begränsningar men avancerade klurigheter var ingen långsiktig lösning. Konventionell Electronic Data Interchange - EDI är sedan länge en självklarhet vid utbyte av handelsdata mellan de flesta större företag samt för annat utbyte inom specifika sektorer av näringslivet. Konventionell EDI är dock inte Internet-baserad samt har även i andra avseenden egenskaper som inte gör det alldeles attraktivt för de nya förutsättningar och krav e-commerce ställer upp. Se vidare nedan tillsatte World Wide Web Consortium (W3C) en arbetsgrupp för att ta fram en enklare version av SGML enligt principen: hitta de 20 procent av SGML som klarar av att lösa 80 procent av alla behov. Vilket man enligt allas uppfattning lyckades med i form av den på våren 1998 antagna rekommendationen (W3Cs synonym för 'standard') Extensible Markup Language (XML) extensible Markup Language (XML) 1.4 Fortsättning följer Både det snabbt framväxande e-commercefältet och ett alltmer sofistikerat samhälle ställer krav på smidiga kontakter med omgivningen för att inhämta och leverera information, för att utföra komplexa, gemensamma operationer, för att generera eller reagera på händelser, med mera. Dessutom ändrar denna omgivning kontinuerligt karaktär och omfattning. Vilket även gäller den egna verksamheten i form av nya behov, krav, avtal, lagstiftningar, affärsidéer, m.m. Globala nät baserade på öppna, standardiserade gränssnitt kommer ge upphov till globalt distribuerade tillämpningsmiljöer där funktion, tjänst eller service realiseras som fristående komponenter i mer eller mindre komplex samverkan och där dessa komponenter lever och dör, tillåts vara mobila, kan replikera sig, fatta egna beslut, kanske vara dynamiskt läraktiga. Med öppenhet följer krav på fungerande lösningar vad gäller säkerhet, kvalitet, behörighet.

10 Vi lever i en rörlig tid med snabba kast. Knappast glädjande för den som söker stabila omständigheter, vill kunna formulera långsiktiga strategier, hoppas på säker återbäring på teknikinvesteringar, vet att återvändsgränder kan vara livsfarliga inte bara ur en teknisk synvinkel utan för verksamhetens överlevnad. Men potentialen är enorm. Vilka nya tillämpningsvärldar kan inte nu öppnas för den kreative. Vad kommer de närmaste åren föra med sig?

11 2 XML teknikperspektivet 2.1 Dokumentinnehåll XML bygger i princip på att framför varje element i ett dokument placera ett väl valt märkord som förhoppningsvis beskriver hur elementet ska tolkas. Märkordet är knappast en fullödig semantisk beskrivning av innebörden, men i många fall tillräckligt för att ge den korrekta förståelsen. Speciellt om parterna dessförinnan "vid förhandlingsbordet" kommit överens om betydelsen av de nyttjade märkorden. XML erbjuder därutöver en hierarkisk uppbyggnad av dokumentets innehåll ner till valfritt djup. Samt ett antal andra faciliteter vi utelämnar i denna översikt. Antag att vi har ett orderdokument med innehåll och layout enligt figur a. Bortser vi nu från orderns layout har den ett hierarkiskt innehåll enligt figur b. Ordern består av fyra olika typer av underelement (Ordernr, Kund, Orderrad och Summa), varav Orderrad upprepas två gånger. Kund och Orderrad står i sin tur för varsin grupp underelement, Kunds Namn, Adress och Orderrads Produkt, Antal och Apris. Kund: Order Stina Storgatan Produkt Antal Apris Ordernr: 123 Vilstol Lampa Summa att betala: 3500 Order Ordernr: 123 Kund Namn: Stina Adress: Storgatan Orderrad Produkt: Vilstol Antal: 4 Apris: 500 Orderrad Produkt: Lampa Antal: 6 Apris: 250 Summa: 3500 Figur a Figur b Eftersom XML enbart uttrycker innehåll, inte dess layout, är det strukturen i figur b som ska formuleras på ett sätt som kan skickas och tas emot på ett entydigt sätt. Att skicka information över ett nät innebär att skicka en ström av bitar, i XMLs fall i form av textsymboler. Alltså gäller det att framför varje element med hjälp av ett inledande märkord tala om hur det ska tolkas så att det kan tas om hand på rätt sätt. Lika viktigt är det att indikera elementets slut för att undvika missförstånd. Ta exempelvis Stina. Vi vill tala om att Stina är ett namn. Märkordet bör med andra ord vara 'namn'. För att skilja märkord från övrig text omges det med hakparenteser. Ett inledande märkord matchas alltid med ett likalydande avslutande märkord men där det senare indikeras med ett snedstreck direkt innanför den första hakparentesen. Vi erhåller: <namn>stina</namn> Därefter kompletterar vi med adressuppgift enligt

12 <namn>stina</namn><adress>storgatan</adress> Dessa två uppgifter är vad som beskriver kund något vi talar om genom att omge uppgifterna med kund-märkord enligt: <kund><namn>stina</namn><adress>storgatan</adress></kund> eller mer överskådligt enligt <kund> <namn>stina</namn> <adress>storgatan</adress> </kund> Gör vi sedan samma sak med de två orderraderna, inkluderar ordernumret och summan samt talar om att alla dessa uppgifter tillsammans är en order genom att omge dem med 'order'- märkord blir resultatet enligt figur c. <order> <ordernr> 123 </ordernr> <kund> <namn> Stina </namn> <adress> Storgatan </adress> </kund> <orderrad> <produkt> Vilstol </produkt> <antal> 4 </antal> <apris> 500 </apris> </orderrad> <orderrad> <produkt> Lampa </produkt> <antal> 6 </antal> <apris> 250 </apris> </orderrad> <summa> 3500 </summa> </order> Figur c Dokumentet är nu entydigt definierat till sitt innehåll och sin struktur. 2.2 Dokumentmallar Den explosionsartade utvecklingen av webbtillämpningar för e-commerce liksom för generell distribuerad samverkan mellan såväl företagens interna tillämpningar som dess externa kontaktytor med andra företag i och för fullgörandet av allehanda affärsprocesser ställer nya

13 och allt hårdare krav på standarder för datautbyte. När det gäller B2B-samverkan 2 är vanligtvis fokus endast i begränsad utsträckning mot presentation av dokument men desto mer mot utbyte av strukturerade data. Det kan gälla data som utbyts mellan egna och/eller andras tillämpningar eller mellan avsändares och mottagares respektive databaser där källmaterialet kanske kommer från flera databaser och där målet hos mottagaren också kan vara flera databaser. Kanske är kontakten mellan de av mänsklig hand inmatade uppgifterna och den tillämpning som står för den fortsatta bearbetningen. Det är gott och väl att ett dokument i och för datautbyte kompletteras med informerande märkord eftersom innehållet då lättare kan tolkas. Men i många av sammanhangen enligt ovan räcker inte detta. Man behöver vara överens om exakt vilka dokument som ska utbytas och, för varje dokument, exakt vilket innehåll det ska ha. Dokumentet har en given roll att fylla och måste svara mot förväntade kvalitetskrav. En order ska alltid innehålla vissa element. Andra element är frivilliga. Ytterligare andra element kanske får upprepas flera gånger, t ex orderrader. Villkoren stipuleras lämpligen i form av mallar föreskrivande vad som kan accepteras. XML innehåller syntax för att uttrycka mallar. Dessa mallar kallas för Document Type Definitions (DTD). Låt oss återvända till orderdokumentet. Dess struktur är enligt figur d. Samma sak som ett hierarkiskt träd visas i figur e. Order Ordernr Kund Namn Adress Orderrad Produkt Antal Apris. Ordernr Kund Order Orderrad Summa Summa Namn Adress Produkt Antal Apris Figur d Figur e Samtliga orderdokument antar vi måste följa samma innehållsstruktur. Vi väljer att uttrycka detta i en generell typbeskrivning - en DTD. På översta nivå finns order med dess fyra typer av underelement. I XML deklareras översta nivån enligt: <!ELEMENT order (ordernr, kund, orderrad+, summa)> Som synes finns ett plustecken efter orderrad. Tecknet indikerar villkoret att antalet orderrader kan vara ett eller flera (1:M). Varje typ av underelement måste i sin tur deklareras. Vi börjar med ordernr: <!ELEMENT ordernr (#PCDATA)> 2 Business to business elektroniska affärer mellan företag.

14 Ordernr uttrycks som #PCDATA vilket står för Parsed Character Data, d v s text som kan identifieras. DTD-syntaxen saknar möjlighet att precisera acceptabel datatyp, t ex att det måste vara ett heltal. Kund deklareras därefter: <!ELEMENT kund (namn, adress?)> Som synes är kund sammansatt av namn och adress. Frågetecknet efter adress indikerar att uppgiften får förekomma ingen eller en gång (0:1). På samma sätt som ordernr ovan deklareras därefter namn respektive adress: <!ELEMENT namn (#PCDATA)> <!ELEMENT adress (#PCDATA)> Deklarerar vi därefter på samma sätt orderrad och dess underelement samt summa. Resultatet blir den samlade deklarationen enligt figur f. Överst i dokumentet anger vi att vi har valt att kalla DTD-mallen (doctype) för 'order'. Hakparenteserna markerar deklarationens början och slut. <!DOCTYPE order[ <!ELEMENT order (ordernr, kund, orderrad+, summa)> <!ELEMENT ordernr (#PCDATA)> <!ELEMENT kund (namn, adress?)> <!ELEMENT namn (#PCDATA)> <!ELEMENT adress (#PCDATA)> <!ELEMENT orderrad (produkt, antal, apris)> <!ELEMENT produkt (#PCDATA)> <!ELEMENT antal (#PCDATA)> <!ELEMENT apris (#PCDATA)> <!ELEMENT summa (#PCDATA)> ]> Figur f Dokument som är korrekt formulerade i enlighet med XML-syntaxen kallas "well-formed". Ett dokument kan även sättas att peka på en DTD varmed underförstås att dokumentet anses vara av den utpekade typen. Med referens till en DTD kan dokumentets innehåll, inte bara dess syntax, testas för korrekthet. Svarar dokumenten mot villkoren i refererad DTD kallas det för ett "valid" dokument. DTD Dokument Dokument Well-formed Document (XML-korrekt) Valid Document (DTD-korrekt)

15 Figur g Förutom att användas för dokumentkontroll kan en DTD lämpligen biläggas avtal som parter förmodligen önskar teckna för att reglera formerna för planerad samverkan. 3 DTDer saknar viss uttryckskraft som visat sig vara angelägen för korrekt hantering vid många typer av dokumentsamverkan. Dit hör rikare möjligheter att ange strukturvillkor. Idag kan plustecken (1:M), asterisk (0:M) och frågetecken (0:1) användas för att ange antalsvillkor. Förfinade villkor som exempelvis 0:3 eller <1000 kan inte formuleras. Inte heller går det att precisera vilken datatyp som ska gälla för ett löv-element (annat än #PCDATA). Något som visat sig vara en besvärande brist i många situationer. Det kan exempelvis vara viktigt att kunna deklarera att ordernr är ett fyrsiffrigt heltal eller att summa inte får vara större än kronor samt alltid anges inklusive ören. Förutom standarddatatyper bör egna datatyper kunna specificeras för unika behov, t ex olika typer av tidsintervall och symbolsekvenser. W3C har därför initierat en arbetsgrupp under arbetsnamnet XML Schema vars arbete förhoppningsvis ska utmynna i ett rikare språk - speciellt vad gäller datatyper och preciserande villkor och bindningar - än vad som idag står till buds för DTD-specifikationer. XML Schema kommer, om och när det blir en antagen rekommendation, att kunna ersätta den nu tillgängliga DTD-syntaxen. Flera separata förslag har lämnats in. Enligt många bedömare lär det dröja ett bra tag innan en standard föreligger, kanske först under år Möjligtvis kan pressen från marknaden komma att snabba upp processen. 2.3 DTD-vokabulärer Antag att två parter kommit överens om att utbyta dokument svarande mot tre DTDdeklarerade dokumenttyper. Figur g Allt är förmodligen under kontroll och rimligt hanterbart. Men de flesta företag har inte bara kontakt med en affärspart. Vi kompletterar med ytterligare två företag och hamnar i en situation liknande figur h. Nu är det plötsligt inte lika överskådligt längre, trots att det maximalt utbyts tre dokumenttyper per samverkande par. 3 Det är en öppen fråga vilken rättslig betydelse en sådan biläggning skulle ha.

16 Figur h Vi kan bara ana hur det skulle se ut för ett företag som har 20 leverantörer, ett otal kunder, ett antal myndigheter och diverse andra att utbyta dokument med, förmodligen många gånger i för företaget kritiska affärsprocesser. Ohållbart! Dominerande företag kan visserligen diktera ett dokuments uppbyggnad genom att ställa det som ett krav för att en affärsrelation ska inledas. I det framväxande e-commerce blir affärsprocesserna sannolikt betydligt mer inflätade mellan många intressenter och över många roller. Ett dominerande inflytande kan inte lika självklart etableras. Istället behövs renodling och standardisering. Ta de 20 leverantörerna. Kanske utbyter företaget i de allra flesta fall i stort sett samma typ av dokument med var och av dem. Dessa leverantörer har förmodligen i sin tur leverantörer som man utbyter data med enligt i stort sett samma mönster. Varför inte om möjligt en gång för alla standardisera en rimligt heltäckande uppsättning dokumenttyper som har relevans inom det avgränsade området, var och en med ett genomtänkt innehåll. Då behöver ju inte detta specifikationsarbete upprepas varje gång nya parter ska komma överens om och realisera liknande datautbyte. "Gröten" ovan kanske kan ersättas med nedanstående figur där parterna efter visst kompromissande kommit överens om att renodla umgänget till endast fyra dokumenttyper utan att för den skull förlora i informationsinnehåll.

17 Gruppen har enats om vad som allmänt kallas en dokumentvokabulär (figuren till höger). Självfallet måste en vokabulär formuleras av dem som känner syftet utan och innan samt har datautbytesbehoven. Branschorganisationer, företagarföreningar eller andra rimligt stora och ansvarskännande sammanslutningar är typiska exempel. Ett ansvar många organisationer för övrigt redan tagit på sig eftersom insatsen är angelägen men också för att det med XMLsyntaxens hjälp är skäligen enkelt för vem som helst att syntaktiskt korrekt definiera en uppsättning dokumenttyper. Dessa bransch- eller tillämpningsområdesspecifika så kallade vokabulärstandarder, eller vokabulärer, dyker nu följdriktigt upp i strid ström. Däri ligger såväl en styrka och fara. Styrkan ligger i att parterna tydligen lyckas komma överens. För detta krävs både en genuin förståelse för de egna behoven och hur de relateras till de övrigas. Varje element som är resultatet av en omfattande kompromiss - måste noga definieras till sitt syfte och sin innebörd. Alla nyanser måste redas ut. Rätt avgränsade, rätt formulerade och rätt använda kan de komma att spela en mycket effektiv roll som normbildare och kvalitetshöjare för datautbyte. En angenäm och viktig följdeffekt blir förhoppningsvis en ökad förståelse för vikten av och ett allmänt ökat intresse för de semantiska aspekterna kring datahantering och datautbyte. Faran ligger i den "Klondyke-eufori" som nu tycks sprida sig kring vokabulärstandardisering. Går det för fort? Sker det alltid baserat på välgenomtänkta syften? Bland frågeställningar att ta ställning till kan nämnas: * Hur omfattande, heltäckande ska en vokabulär vara? Hur bör ämnesområdet lämpligen avgränsas? Vad är eftersträvansvärt i skalan från en enda DTD till en stor uppsättning DTDer? Vad finns gjort på andra håll? Finns överlappningar? Risk för diskrepanser? * Ska, givet ett avgränsat ämnesområde, ansatsen vara att endast standardisera en minsta uppsättning okontroversiella element - en minsta gemensam nämnare - som alla snabbt kan samsas kring? Ska ansatsen istället vara att i en DTD få med allt för att tillgodose allas önskemål? Är det överhuvudtaget möjligt med tanke på semantiska nyanser, mm? * Vilken grad av förankring och samordning bör eftersträvas? Bör den ligga på branschnivå eller kan den lilla företagarföreningen i kommunen formulera sin egen vokabulär? Eller ska båda versionerna om möjligt kunna samexistera? Vad gör man om de på vissa punkter kommer i konflikt med varandra? Vad ligger i den kommersiella vågskålen av för- och nackdelar för det företag som själv väljer att utveckla och föra ut en vokabulär inom sin domän? * Vilka krav ska ställas på uppslutning bakom en vokabulär för att den ska föras ut som standard?

18 * Vilken roll ska vokabulären spela? Ska den vara bindande eller rådgivande? Om det förra, hur ska efterlevnaden drivas på, kontrolleras? Om det senare, ökar risken för fragmentarisering och inkompatibilitet eftersom alla som så önskar kan modifiera den. * En vokabulär har en livstid under vilken den behöver felrättas, anpassas, vidareutvecklas. Vem bör rimligtvis ta på sig det långsiktiga ansvaret? Med vilken rätt? Vad innebär ansvar? Hur hanteras helt allmänt konflikter mellan vokabulärer och överlappande vokabulärer? * Vad är generellt sätt eftersträvansvärt; genomarbetade, stabila standarder eller anpassbara, flexibla dito? Har man tagit i beaktande de möjliga konsekvenserna av de två alternativen? Dessa frågor är endast ett urval av de frågor som måste diskuteras aktivt inom standardiseringorgan, branschorgan m.m.. Ingen vet ännu de goda svaren. Vi träder in i en global och allomfattande samverkansmiljö som långt ifrån ännu hittat sina färdiga former. Vad som däremot är säkert är att turbulensen kommer att blir stark, att många viljor under överskådlig tid kommer att råda och att marknadskrafter till sist kommer att spela den avgörande rollen. Någon stabilitet är knappast att någonsin förvänta i en elektronisk värld som kännetecknas av alltmer snabbföränderliga förutsättningar med nya spelregler, nya aktörer, nya affärsprocesser, ny teknik och nya behov. Den andra delen av denna rapport går igenom ett antal av dessa initiativ för att visa på deras mångfald och i vissa fall deras uppbyggnad. 2.4 Att arbeta med ett mottaget dokument HTML-dokument skickas huvudsakligen till någon webbläsare för presentation. XMLdokument kan visserligen användas på samma sätt men dess primära användning bedöms bli för den typ av datautbyte som diskuterades i inledningsavsnittet oavsett om det ligger inom kategorin B2C eller B2B.. I båda fallen behöver vi på alla upptänkliga sätt kunna arbeta med dokumentets ingående element. Antag att ett orderdokument anländer till vårt tidigare företag Firma Säljer Allt, närmare bestämt till dess Ordermottagning-service. Ordermottagning Orderns alla element registreras först och främst i en orderdatabas samtidigt som ett urval av elementen uppdaterar en kunddatabas. Kunddata sänds också till bankens Kreditkontroll. Ordern i sin helhet kompletteras med diverse leverantörsuppgifter (Paket Ohoj upa betjänar flera företag) och sänds vidare till Leverans-servicen. Väl där sker registrering i en lokal databas och uppgifter skickas om beställda produkter och antal tillsammans med ett nygenererat leveransnummer till den leveransansvariges PDA. 4 Och så vidare. Det är tydligt att orderns ingående element måste kunna urskiljas och användas vidare för olika syften. 4 Personal Digital Assistent handdator.

19 Kontroll av dokumentet och uppdelning i dess beståndsdelar utförs i allmänhet med hjälp av en så kallad XML Parser (det finns flera att gratis ladda ner från webben). Eftersom de olika elementen behöver kunna vidarebearbetas på olika sätt enligt ovan, måste parsern kunna lämna ifrån sig elementen i en form som gör detta möjligt. W3C har tagit fram standarden Document Object Model (DOM) just för detta behov. DOM definierar en hierarkisk struktur enligt vilken alla element entydigt placeras in. DOM innefattar därutöver ett tillämpningsgränssnitt (API - Application Programming Interface) via vilket olika typer av operationer på strukturen kan begäras. Med APIets hjälp kan man både söka fram, ändra, radera, lägga till och placera om element, d.v.s. i stort sett allt som överhuvudtaget kan tänkas behöva utföras på och med dokumentet i och för de fortsatta operationerna. I figur i tittar vi innanför skalet på Orderbehandling. XML-parsern tar emot dokumentet. I den mån dokumentet refererar till en DTD, vilket vi förmodar är normalfallet i de flesta välgenomtänkta sammanhang, utnyttjar parsern även denna information för att bättre kontrollera dokumentets innehåll. Ut kommer en hierarkisk DOM-struktur. Den lagras i primärminnet. Programmoduler (objekt, komponenter, ) har sedan möjlighet att bearbeta strukturen via APIet. DOM (Document Object Model) DOM API XML- parser Programmodul Figur i Ett annat alternativ är att utnyttja SAX (Simple API for XML), ett händelsebaserat API. I detta fall upprättas ingen intern dokumentstruktur. Istället informerar parsern programmodulen vad den hittar allteftersom den går igenom dokumentet (nu kommer kunddata, nu är det slut på kunddata, nu kommer namn,.). SAX är lämpligt bland annat när man har mycket stora dokument som kräver avsevärt arbete för att upprätta en DOM-struktur. Framförallt kommer dock SAX till sin rätt när man bara är intresserad av något enstaka element i dokumentet. Programmodulen väntar lugnt tills just det efterfrågade rapporteras från SAX. Att i det läget upprätta en DOM-struktur är onödigt slöseri med resurser.

20 SAX (Simple API for XML) XML- parser Programmodul I båda fallen är det därefter fritt fram för programmodulen att arbeta vidare med dokumentdata på avsett sätt. Det kan vara att anropa någon annan modul för vidare arbete på strukturen. Kanske väljer modulen att anropa en annan modul med hjälp av något middleware som ställer unika krav på meddelandeuppbyggnad. Modulen kan skapa meddelanden efter de aktuella reglerna genom att extrahera de erforderliga elementen och placera in dem i meddelandet. Kanske väljer modulen att skapa ett nytt dokument med sitt unika innehåll i och för anrop till någon extern service alternativt för hantering inom någon databashanterare. Kanske väljer man att med hjälp av några element i dokumentet istället formulera en SQLinstruktion. Självfallet kan man också med olika teknik välja att presentera valda element ur dokumentet. Görs presentationen i en webbläsare skapar modulen lämpligen ett HTMLdokument för vidare transport till webbläsaren. Med flera olika varianter.? SQL DB.. Möjligheterna är närmast obegränsade även om DOM-API inte är det mest lättillgängliga, dessutom på en ganska detaljerad hanteringsnivå. Av den anledningen har W3C initierat en DOM2-aktivitet som man hoppas ska utmynna dels i nya objektmodeller, bland annat en för Cascading Style Sheets och en för Events, dels i ett betydligt rikare API. Det har också inkommit förslag om att tillföra ett frågespråk under beteckningen XQL (extensible Query Language) som på ett elegantare sätt ska erbjuda sökmöjligheter i strukturen. Om och när XQL är ännu alltför tidigt att sia om. 2.5 Presentation XML formulerar innehåll, inte layout. Ska dokumentet presenteras måste alltså layoutinformation tillföras dokumentet. Detta kan ske på i stort sett samma sätt som för HTML, d v s genom specifikation av layouten i ett så kallat style sheet en formatmall, exempelvis Cascading Style Sheets (CSS), en standard också framtagen av W3C. CSS kan användas både för HTML- och XML-dokument för att föreskriva önskad layout. För XML-