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 ogantall 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 spesielt se på anvendelse 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:

• XML er velegnet format hvis målet er en redaksjonell prosess, mens en skal publisere i flere formater/medier. På dette området har SGML lenge vært nærmest enerådene og arven fra SGML kom tydlig frem i erfaringsbakgrunn til foredragsholderne. (Presentations oriented publishing.)
• Lagring og vedlikehold av store datamengder med strukturert informasjon. Objektorienterte databaser, dokument styringssystemer.
• XML-meldingsutveksling og systemintegrasjon. Deriblandt XML/EDI.

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 :

• Paul Prescod, Isogen Corporation, XML an JAVA: Working together
• Joseph Gollner, Xia Information Architechts. Guidelines for using XML and EDI
• David Megginson, Megginson Technologies Ltd. How Interchangeable is XML, anyway?
• Linda Burman, L.A. Burman Associates, Tools Survey

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>). Element kan inneholde andre elementer. På denne måten kan man lage hierarkiske strukturer av elementer.

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 sammenhenge 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. (hilsen Microsoft og Netscape)	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.	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	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 blandt 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:

• ArborText
• Infrastructure for information
• Interleaf
• Omnimark

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 veldig liten forskjell på EDIFACT og XML. Begge:

• Er ASCII baserte hierarkiske meldingsformater
• Har en spesifisert spesifisert struktur som meldingsinstanser skal matches mot (Implementasjonsguide / DTD)
• Er avhengig av transport og sikkerhetsmekanismer hos andre tjenester
• Må valideres syntaktisk ved mottak
• Er i utgangspunktet best egnet for asynkron meldingsutveksling

Viktig forskjell er:

• Data som på et eller annet tidspunkt skal presenteres for sluttbruker vil ha store fordeler av å være på XML format. Fordi XML format vil kunne presenteres direkte i browsere og tekstbehandlingssystemer uten noen form for format konvertering.
• XSL stylesheetes gir mulighet for å skreddersy layout og håndterer presentasjonsmanipulering av data på klient.
• Naturlig lagringsteknologi for XML dokumenter vil trolig være ODBMS. Det er selvsagt ingenting i veien for å benytte ODBMS'er for EDIFACT, men det er ikke meg kjent at det er gjort i noen utstrekning i Norge. Dette kan trolig ha historiske årsaker knyttet til når RDBMS'er og senere ODBMS'er ble kommersielle produkter.

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 fordragsholderne ikke skjønner hvilke elementer det er som gjør eCommerce komplisert. Det gjelder alt fra rammebetingelse, systemutvikling & systemdrifting til business modellering og avtaleetablering.

XML og elektronisk handel

(Går i dette avsnittet 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 proseseres 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 kviteringer 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:

• utvekslet informasjon om partenes infrastruktur og krav til sikkerhet. Dette ordnes on the fly av IT-systemene som dynamisk setter opp de protokoller og sikkerhetsmekanismer som trengs.
• har utvekslet noen informasjon om hva intensjonen med en melding faktisk er
• inngått noen handelsavtale, betalingsbetingelser eller relasjoner til hvilket juridisk domene handelen skal foregå under.
• blitt enig om hvilke aksjoner/ interne aktiviteter mottaker skal iverksette og tilhørende kvitteringsmekasnismer

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 kanseleres, 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 innkommen XML-melding er i henhold til en DTD (grammatikk) som er relevant for aktuell melding. Det vil begrense mengden av permuteringer. Men:

• hvem skal definere taggene?
• hvem skal spesifisere strukturen til DTD'ene?
• skal en ha en ordre for hele Internett?
• skal VVS bransjen lage sin egen "XML-ordre melding", hvor de henter noen av taggen fra et ordre-repository?
• er avtalen inngått ved avsending av ordre, eller mottak av ordre, eller må det en ordre bekreftelse til får at avtalen skal være gyldig.

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 forran 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 etterhver 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…

29. september 1998
Hilsen
Per Myrseth