Reisebrevet er ikke ment som et tungt akademisk velfundert verk, men et kort og "muntlig" reisebrev, og må leses med det i minnet.... ;-)

29. september 1998, Per Myrseth, NR


Reisebrev fra XML World 98, 15-17. september, Ottawa

Melding 1 :

Isolert sett er XML lite spennende og langt fra noen silverbullet. Det er timing, tilbehør og antall leverandører og applikasjoner som på en eller annen måte støtter XML som gjør XML veldig interessant.

Melding 2:

Gem'ere kunne presentert eCommercefaglig innhold som hadde gått utenpå flere av foredragsholderne.....

Mål med reisen

Å lære mest mulig om XML og spesielt se på anvendelse av XML innen elektronisk handel.

Foredragene

Det var stor spredning på foredragsholderne, men stort sett var det bra presentasjoner. Det var to parallelle sesjoner, teknisk og management. Jeg gikk stort sett på de tekniske presentasjonene.
Hovedgrupperinger av presentasjonene:

Jeg synes en del av presentasjonene var veldig ukritiske i forhold til hva XML faktisk kan løse av problemer. Jeg synes de fire beste presentasjonene var :

De tre førstnevnte av disse presentasjoner sørget for litt bakkekontakt i forhold til hva en kan forvente av XML. Sistnevnte, Tools Survey var veldig nyttig med tanke på å få oversikt over hvilke produkter som finnes og hva en kan forvente av dem.

XML in a nutshell

  1. Primært bruksområde: Strukturering av dokumentinnhold.
  2. Konseptmessige "foreldre": SGML og HTML
  3. Lagrings og utvekslingsformat: ASCII

Et XML dokument er et stykke tekst eller data som er tagget og strukturert i henhold til spesifikasjonen for XML standarden. Et XML dokument inneholder et eller flere elementer. Et element består av en start tag, et innhold og end tag (eks. <author> Ola Nordmann</author>). Et element kan inneholde andre elementer. På denne måten kan man lage hierarkiske strukturer av elementer.

Digresjon

En konferanse som skal handle om et format for strukturering av dokumenter, noe som utgjør en brøkdel av kompleksiteten knyttet til elektronisk handel. Hvorfor selger det så bra? Er det fordi at i relasjon til elektronisk handel er dokumentformater tross alt et av de mer konkrete elementene som er lett å forstå?

Skudd fra hofta:

Etter å ha hørt på hvordan en del av foredragsholderne råselger XML som løsningen på det meste, tror jeg det er viktig å vær litt kritisk til hva en faktisk kan vinne ved å benytte XML kontra andre tilsvarende konsepter. Det gjelder både gevinster i forhold til SGML, men også i relasjon til elektronisk handel standarder som EDIFACT. Jeg tror egentlig at store dele av IT-bransjen deri inkludert IT-pressen og en del av foredragsholderne ikke skjønner hvilke elementer det er som gjør eCommerce komplisert. Det gjelder alt fra rammebetingelser, systemutvikling & systemdrifting til business modellering og avtaleetablering.

XML tilbehør og relaterte begreper

Til selve XML kommer det en samling av tilbehør som en kan eller bør benytte seg av. Mye av tilbehøret er ikke å betrakte som fullverdige versjoner av standarder, men forslag basert på at en leverandør har laget en konkret implementasjon eller et konkret grensesnitt. Det er på flere områder konkurrerende standardiseringsforslag.
(Understående tabell som lister termer knyttet til XML er ufullstendig, men med mer hjelp fra Gjertrud K. og andre så blir det nok bra til slutt.)

XML hovedelementer   Kilde/ ansvarlig Alternativ til/ utvidelse av
XML eXstensible Markup Language, er et tekstbasert format for å spesifisere strukturert informasjon eller strukturerte dokumenter W3C  
XML dokument Et stykke tekst eller data som er tagget og strukturert i henhold til spesifikasjonen av XML standarden. W3C  
XML melding Et XML dokument som brukes for å utveksle data mellom datasystemer.    
Struktur      
DTD Document Type Declaration, definerer hvilke tagger som kan brukes og hvordan de kan nøstes. En DTD blir er også kalt markeringsspråk eller grammatikk. W3C XML-data
XML-data Er et forslag for å beskrive XML dokumenters struktur, ved å bruke XML som notasjon. W3C DTD
Linking      
XLL/Xlink Extensible Link Language, kompatibel med URL, linker direkte til elementer i et annet dokument, indirekte linker (en link kodes til en linktabell, hvor denne linktabellen igjen peker til faktisk kilde). W3C  
Layout      
XSL Extensible Style Language, beskriver hvordan XML-dokumentet kan/skal presenteres (layout). XSL beskrivelser noteres i XML syntaks. W3C CSS / DSSSL
CSS Cascading styles sheets. Tillater bl.a. layouttagger i HTML dokumenter.    
Annet      
Namespace Når en XML melding skal settes inn i en ny XML sammenheng, vil den nye sammenhengen allerede ha et etablert sett av tagger. Da vil det kunne oppstå navnkollisjoner mellom det nye XML dokumentet og det etablerte begrepsapparatet. Namespace lager regler for dette problemområdet. W3C  
XML repository Ved utveksling av XML dokumenter er det viktig at avsender og mottaker benytter de samme taggene. Det er derfor hensiktsmessig å opprette et repository over tagger som kan benyttes i en kontekst. Da kan alle aktører i denne konteksten benytte samme tagger. Dette vil være en kjempefordel for systemintegrasjon. W3C  
DOM Et platformuavhengig API mot XML dokumenter. Skal kunne brukes til å create/update/delete deler eller hele XML dokumenter. Versjon 2 går i retning av å skulle håndtere queries, UI, Validation, styles, filters…… W3C  
URI Uniform Resource Identifier W3C  
UML Unified Modeling Language OMG  
Xpointer      
Xschemas      
API'er og Metadata      
RDF Resource Description Format/Framework?. Et forslag på hvordan en skal beskrive hva et XML dokument betyr. IBM/?  
SAX Simple API for XML    
XMI XML Metadata Interchange    
MOF Meta Object Facility, OMG Repository standard for distributed repositories and meta-data management.    
WIDL Web Interface Description Language, har konseptmessige likehetstrekk til IDL for CORBA webMethodes  

Ryktebørsen…

Microsoft og Netscape kommer begge til å støtte XML. J Det betyr i praksis at hvis det er penger i det så kommer de begge til å støtte minst fremvisning av XML dokumenter i sine browsere.
Microsoft bruker XML i sine systemer allerede for lagring av "ini-filer" oa. K Et godt tegn, men det er verd å merke seg at dette er den enkleste form for bruk av XML. Både avsender og mottaker av informasjon er samme applikasjon.
Hørt og lest: Officepakka skal lagre i XML format L Korreksjon fra Microsofts representant: Officepakka skal lagre i HTML, men som en del av HTML skal det lagres nok skjult XML til at hele dokumentet som ble lagret inkl. formler, innholdsfortegnelse, nummererte lister mm. skal kunne gjenskapes når du leser det inn i riktig officeapplikasjon.
XMI, UML skal kunne utveksles mellom CASE verktøy i XML format.   Ingen av CASE verktøy leverandørene var tilstede og bekreftet utsagnet, men flere av foredragsholderne sa så.
Det ble sagt at DTD er noe en midlertidig benytter inntil en har noe bedre? Helst noe som baserer seg på XML som lagringsformat.   Delte meninger blant foredragsholderne og W3C representantene

Interoperabiliteten kontra fleksibilitet

Da Microsoft og Netscape hver for seg introduserte egen HTML-tagger for browserne sine, ble HTML-dokumenter skreddersydd for den ene browseren ugyldig på den andre. Nå som vi skal bruke XML kan alle lage sine egne tagger og allikevel kan XML-dokumentet være syntaktisk korrekt. I forbindelse med elektronisk handel så skaper dette en utrolig fleksibilitet, men hvordan går det med interoperabiliteten?

Firmaer og produkter:

Det var en del produktleverandører som hadde stands i konferanselokalet. Følgende firmaer oppfatter jeg som såpass interessante at vi bør holde et lite øye med dem i fremtiden:

Sammenlikning av XML og EDIFACT

Dette avsnittet er en egenvurdering som jeg kommer til å massere videre på. Med utgangspunkt i at XML skal benyttes som meldingsformat til handelsdokumenter så er det liten forskjell på EDIFACT og XML. Begge:

Viktig forskjell er:

XML og elektronisk handel

(I dette avsnittet går jeg litt ut over det å referere fra selve XML konferansen, men strør heller ut noen tanker rundt XML og eCommerce basert på ny erfaringene fra konferansen.)
En handelstransaksjon foretatt i et åpent nett, som skal kunne prosesseres automatisk kan hensiktsmessig deles inn i tre hovedfaser.

  1. Initiering: Partene finner hverandres profiler og etablere teknologisk kontakt.
  2. Utførelse: Data som gjør ønsket handelstransaksjonen mulig utveksles, og partene aksjonerer/igangsetter interne aktiviteter basert på de data som utveksles.
  3. Terminering: Avlutter utførelsen og sjekker at alle tilstander og kvitteringer er ok.

XML er velegnet som dataformat i alle tre fasene. For at XML skal tilføre noe mer enn bare dataformatet, må vi ta i bruk XML tilbehøret.
Det interessante området for XML sett i forhold til elektronisk handel er om en får til at aktører i en handelstransaksjon kan aksjonere på XML-dokumenter som mottas, uten at en på forhånd har:

Det er ikke gitt at en XML-melding definert ved type ordre, som kommer tuslende over Internett til en leverandør, skal behandles i henhold til "handelstradisjoner i VVS bransjen på vestlandet". Hva om ordren inneholder betingelser og krav som leverandøren ikke ønsker å godta? -- Når blir egentlig avtalen inngått, hvordan kan den eventuelt kanselleres, hvordan håndteres alle mulige feilsituasjoner som gjør at handelen ikke fullføres ?
Det vil være til god hjelp om alle taggene i innkomne meldinger er i henhold til en standard for aktuell meldingstype. Da kan mottaker tross alt knytte sin tolkning av innkommende melding opp mot standard tagger for meldingen og han har en hvis sjanse til å forstå hvilke felt som er tall, benevnelser til tall, hvilke som er tekst mm.. Selv om en forstår taggene så må den som mottar en XML melding kunne håndtere alle mulige permutasjoner av disse taggene i sine bakenforliggene logistikksystemer. Her igjen ville det være til stor hjelp om en innkommende XML-melding er i henhold til en DTD (grammatikk) som er relevant for aktuell melding. Det vil begrense mengden av permuteringer. Men:

Sett nå at en har både definerte tagger og en har en DTD for ordre. Er vi i mål da? Vel, Jus bør jo være av interesse, hvordan blir jussen i en slik transaksjon, åpen internasjonal handel uten avtale? Jeg tror vi har noen utfordringer foran oss før vi er i mål.


På den andre siden: skal vi løse alle problemer før vi setter i gang? I noen tilfeller vil det være hensiktsmessig å foreta utvikling av systemer, tagger, DTD'er etterhvert som en får erfaringer. Ingen har hittil greid å lage et konsept for handel som mannen i gata og alle store internasjonale aktører benytter på samme måte. Er XML og eCommerce et område hvor veien bør bli til mens en går…