<Reisebrev fra XML 99>

Etter flyturen fra Gardermoen, via Heathrow, til Philadelphia landet jeg med 6 timer jetlag i kroppen. Nok en gang spent på om jeg ville bli imponert over hva XML bringer menneskeheten. Markup Technologies og XML 99 ble arrangert på samme sted på samme tid, så det var mye folk. Ca 2000 personer totalt, og det var omtrent dobbelt så mange som på XML 98 ble det sagt.

Starten og hovedtalerne:

Hovedtalerne første dagen var veldig lite spennende, gamle argumenter som på det beste ble frasert på litt nye måter. Bratte kurver med #web-servere, #XML utviklere og verktøy, #$ m.m. som vertikal aksebetegnelse, dette har vi sett før.

W3C holde en oppdatering på standardene, og i den sammenheng ble det foretatt en gjennomgang av hvordan W3C jobbet. En detalj som kan være verd å merke seg er at W3C som er ansvarlig for utviklingen av bl.a. HTML og XML opererer med tre hovedtilstander av "standarder". Disse er:

Jeg tror ikke jeg overdriver om jeg sier at de fleste av de påfølgende presentasjonene hadde mest fokus på standarder med status "note", deretter hadde presentasjonene fokus på standarder med status "draft" og "recommandation".

Bokhandelen

En ny utgave av "the XML handbook, second edition" av Charles F. Goldfarb og Paul Prescod var lagt ut for salg. Goldfarb er "faderen" til SGML, og Paul var hovedtaler på XML Norge 1998. Når Goldfarb selv satt der og signerte boka så var vel valget ikke så vanskelig. Kofferten ble raskt ½ kiloen tyngre.

Foredragene, utdrag

Så begynte morroa. Track med navnet "Core standards" skulle starte og vi var vel en hundre personer i salen.
(NR internt: Det finnes artikler til alle foredragene, gi lyd om du ønsker kopi av noe.)

XML and Digital Signaturer.

Ved Joseph Reagel, W3C Consortium.

Veldig relevant tema når XML benyttes som syntaks for ehandel eller utveksling av forretningskritiske dokumenter. I utgangspunktet skulle en kanskje tro at en kan ta et XML dokument, lage en signatur over dokumentet og så legge signaturen inn i XML dokumentet i et passende element? Vel, da vil ikke mottaker uten videre kunne sjekke avsenders signatur før  signaturen er tatt ut av det XML dokumentet han har mottatt. Skal en heller sende signaturen separat?

Hva om det er grafikk og annet som skal vises sammen med teksten i XML dokumentet, skal en signere disse andre filene hver for seg? I så fall hvor skal da signaturene legges.

Nå kan en jo ved bruk av CSS, XSL og XSLT styre layout og struktur i et XML dokument. Dvs. bestemme hva som skal presenteres. Signerer en det som ble presentert i en gitt browser på et gitt tidspunkt, eller signerer en selve XML-dokumentet uten hensyn til layout. En bør vel signere på basis av hva en blir presentert, eller? Hvis en signerer det en ser, så er det jo viktig at mottaker ser det samme som avsender. Signaturen vil kun være gyldig for XML dokumentet, så lenge XML dokumentet ikke er endret eller transformert på noen måte. Altså mottaker må ha mulighet for å se dokumentet i samme presentasjonsmiljø som det avsender hadde. Skal i så fall de tilhørende CSS, XSL og XSLT instruksjonene også signeres? Hva da med oppsett på browsere som styrer hvordan bl.a. CSS skal tolkes. Skal dette oppsettet være med i utvekslingen og evt. signeres?

Ville du turt å signere et XML dokument hvis du ikke var helt sikker på hva du egentlig signerte? Så lenge en ikke er 100% sikker på at en har en til en mapping mellom kildedata og det som presenteres, så vil det være veldig vanskelig å lage gode systemer for digitale signaturer.

Vel, dette var en blanding av det foredragsholder la frem under presentasjonen og de spørsmålene han ble bombardert med etter presentasjonen. Det ble skissert noen mulige måter å håndtere overstående utfordringer på. Løsningene fikk jeg ikke helt klart for meg når det ble så mange komplikasjoner å ta hensyn til. Jeg overlater derfor til spesielt interesserte å ta tak i detaljene. Tross alt: XML og digitale signaturer er jo fin lektyre å ha på nattbordet, i tilfelle Dagens næringsliv ringer… ;-)

Se XML and Signatures.

CSS, Cascading Style Sheet

Ved Bert Bos, W3C Consortium

Han ga en bra gjennomgang. Dette tema finnes det mye litteratur på allerede så her gir jeg ikke noe referat. Se : CSS

XSL, eXtensible Style Language

Steve Zilles, Adobe Systems

Han ga en bra gjennomgang. Dette tema finnes det mye litteratur på allerede så her gir jeg ikke noe referat.  Se XSL

SVG, Scaleble vector grafic

Ved Chris Lilley, W3C Consortium

Han startet med å gi alle en klar melding om forskjellen på rastergrafikk og vektor grafikk. Han viste frem hvordan en med 10 linjer forståelig XML kode kunne lage den samme visuelle presentasjon som en animert GIF på 1Mb. Effekt av å benytte dette formatet er: grafikken krever liten båndbredde, men mye prosessorkapasitet på klient/presentasjon siden. Formatet er veldig interessant med tanke på bruk innen mobiltelefoni og presentasjon av grafikk hvor båndbredde er begrenset. I tillegg blir utskrifter av denne type grafikk pen på printere siden den skalerer.

Her har en mulighet for å få stilfulle grafiske bilder med jevne fargeoverganger, dybde effekter, og bildemanipuleringsfiltre, alt prosessert på klienten. Skal en ha med bokstaver i den grafiske presentasjonen, kan en lage en "SWITCH" kommando i SVG syntaksen som sjekker mottakers språkdrakt. Dermed kan en sende en fil som blir presentert på x antall språk (avhengig av hvor mange switch alternativer avsender har tillatt). Se SVG.

SVG Software som finnes allerede:

SMIL Synchronized Multimedia Integration Language

Smil er XML basert språk som skal kunne lime sammen forskjellige typer informasjonselementer til en helhet visuelt og i henhold til tidsaksen. En kan sette sammen informasjonselementenei henhold til plassering i et to dimensjonalt aksesystem (x,y på skjem) pluss at en skal kunne plassere informasjonelementene i forhold til hverandre langs tidsaksen.  Eks. på en web side skal en først kunne vise noe tekst og et bilde, så kommer det lyd som leser opp det som står i teksten, og til slutt skal en kunne vise en video av noe som er relevant for det som tidligere ble vist.

En demo av SMIL skrevet i SMIL spilt av i Realplayer.  Se også W3C sine sider om SMIL.

XML Schemas and Datatypes

Michael Sperberg-McQueen fra W3C og MIT

XML Schemas beskriver strukturen og beskrankningene som skal gjelde for et XML 1.0 dokument. Selve schema språket er ren XML 1.0 syntaks. XML Schemas skal kunne uttrykke det samme som en DTD pluss en del mer.

Mange av presentasjonene bar preg av uklar bruk av begreper og referanser. Michael Sperberg-McQueen var i så måte et klart unntak. Utrolig bra å høre hvordan han som tung fagperson broderte seg gjennom XML Schemas og Datatyper. Hele tiden klarte han å henvise til relevante faglige knagger fra relasjonsdatabaseteori, regulære utrykk, grammatikker mm. som passet for de delene av Schemas han ledet oss gjennom. Han var ikke helt alene om å ha god forståelse om hva han snakket om, men det var få andre som kunne måle seg.

Se XML Schema Part 1: Structures
og XML Schema Part 2: Datatypes

Building a Client-side interactive XML application.

Veldig god presentasjon om hvordan en kan benytte XML/EDI ved bruk av Hovedpunktet i presentasjonen gikk på I alle konverteringer ble det tatt vare på nok informasjon til at en kunne legg tilbake de Xpath pekerne som identifiserte hvert element i det innkomne dokumentet.

Hele spekteret av Xpath, XSLT, XSL, CSS ++ mange av de andre fine forkortelsene var med.

Presentasjonene

Neste år bør GCA som har vært arrangør av XML 99 sørge for å få artikler til gjennomgang, og på basis av gjennomgangen vurdere om artikkelen skal presenteres. Og hvis så, plassere den i en relevant sesjon. Det var flere eksempler på presentasjoner som det ikke var verd å fly over atlantern for å få se.

XML basert ehandel

Med ca. 70 utstillere ble det til at jeg valgte å kikke nærmere på de av utstillerne som reklamerte med løsninger for eCommerce. De fleste utstillerne på XML 99 var sentret rundt strukturering av dokumenter, men det var også en håndfull med fokus på ehandel.  De bedriftene som jeg tittet innom var bl.a. følgende:

Sun: Forte Fusion. Hvis løsningen holder 50% av hva den lovet, så er dette et produkt vi kommer til høre mer om fremover. B2B. Programvaren kjører på en VM (ikke JAVA men en egen Forte VM) Utveksler XML og XSL over HTTP. Har en lagdeling på: Business process logic, Business intergration logic og Functional application logic. Skulle nesten tro de hadde tittet på Open-EDI referansemodellen ;-)

Bluestone XML server, JAVA basert løsning for å utveksle XML over de fleste protokoller. XML serveren skal kunne hente data fra heterogene kilder og sende date fra seg i ønsket XML format på et mangfold av protokoller.

WebMethods, har tre hovedkategorier i sitt konsept. B2B, B2B for portaler og B2B for partnere. MYsap.com kjører på WebMethods programvare. I følge pressen gjør disse gutta det utrolig bra, og de ekspanderer veldig raskt. Hovedkontor i Nederland, Aladin software har rettighetene i Norge tror jeg.

code360, har en XML-server kalt XML-broker. Denne kan motta data fra interne kilder og forta nødvendige konverteringer og så sende data ut til mottaker. Tilsvarende ved mottak.

XML solutions, har konverterer programvare. EDIFACT ó XML og X.12 ó XML konverteringer.

Software AG, med produktet Tamino. En ren XML server (ifølge presentasjonen). Tamino kan motta/hente data fra interne kilder og så sende data ut til mottaker. Tilsvarende ved mottak. Støtter XQL for søking i interne dokumenter

IBM, har det meste for de fleste på de fleste plattformer. Alphaworks er vel en kjent kilde til programvare og informasjon for de fleste som har jobbet litt med XML.

ecomXML, Har produktserien: ecomTalk Server, ecomFrontier, ecomSecurity og ecomCatalogAutomation.

Poet, objektorientert database, men de har noen veldig relevante byggeklosser for en total markedsplass. Bl.a. det de kaller eCatalog suite.

Killdara, leverer Pharaphrase engine, en "server-tjeneste" som kan hente data internt, formatere dem som XML og ved bruk av innebygd PKI, sendes data på ønsket protokoll til mottakere ferdig signert og kryptert.

Oracle, var ikke på XML 99

Microsoft var ikke XML 99

I tillegg var det en rekke aktører som hadde gode løsninger for å få informasjon ut på WEB. Hvis Informasjon er din handelsvare så vil disse løsningene være av stor interesse, men dem har ikke jeg konsentrert meg om.

Geek Cruises, hadde som forretningside å tilby faglige cruise til Karibien, Alaska mm. De pleide å få med seg et av de store navnene innen XML på hver reise. Dette bør jo prøves ut….

XML/EDI

I løpet av presentasjonene som ble holdt fra forskjellige personer fra forskjellige leire, ble det mer og mer klart for meg at foredragsholderne hadde forskjellig tolkning av hva XML/EDI er og hva det skal bli. Per idag så snakkes det om EDI og edi i XML miljøer. Upper case EDI dreier seg om de gode gamle syntakstraverne som EDIFACT og X.12. Mens edi, skal stå for XML basert EDI. Tilsvarende upper/lower-case diskusjon var det i et par år i ISO JTC1 SC 30 knyttet til om Open-EDI skulle ha skrives "Open-EDI" eller "Open-edi". Det endte med Open-EDI, og beslutningen fikk stor applaus. I korridorene ble det etterpå sagt at dette var et stort politisk kompromiss.

XML/EDI er nå blitt en liten familie av varianter som jeg for tiden har følgende forståelse av:

www.ebXML.org, er et initiativ fra UN/CEFACT, ANSI X.12 og OASIS. Initiativet består av ca. 50 organisasjoner. Dette ser jeg på som det mest seriøse og troverdige av initiativene. Dette er et arbeid som Norge bør delta i med støttet av Norsk EDIPRO og NTS.

Det ser for meg ut som om ISIS European XML/EDI Pilot Project fremdeles benytter XML/EDI som begrep og ikke ebXML på foilene når de presenterer resultater fra prosjektet. Om det betyr at de holder seg til David Webber og XML.COM sin begreper og konsepter eller om de er i ferd med å ta hensyn til det som skjer innen ebXML vet jeg ikke. Det kom ikke klart frem i de presentasjonene jeg var på. Om de har valgt å holde på sin eksisterende terminologi og løsningsskisser så er det forståelig ut fra at XML/EDI pilot prosjektet snart skal avsluttes.  De skiller noe på B2B og A2A bruk av XML/EDI.

www.xml.com og deres XML/EDI initiativ, som drives av bl.a. David Webber på basis av aktiviteter på www.xml.com sine mailinglister. David Webber har bl.a. tatt i bruk begrepet BizCodes i sine presentasjoner uten at det har noen direkte sammenheng med Microsoft sitt BizTalk initiativ.

UN-XML, som ser ut til å være et mer privat initiativ fra Dick Raymond. Leder av tidligere EDI Tie, nå kun Tie, fra Nederland.

I tillegg har det eksplodert i "standarder" for hvordan forretningsdokumenter skal utveksles, både når det gjelder syntaks, struktur, semantikk og utvekslingsmekanismer. Noen eksempler på både gamle og nye er:
CXML, Commerce XML by Ariba
Rosettanet
OBI, Open Bying on Internet
CommerceNet
Acord
EDIINT
ANSI X.12
UN/CEFACT
FpML, Financial Products Markup Language
BizTalk

Ehandelsmarkedsplasser, eksempler

www.national.com
www.national.com har fått førsteprisen i en designerkonkurranse for ehandel WEB tjenester.

Mysap.com
mysap.com kan se til å bli et nytt "Amazon" begrep innen ehandel. Mange snakker varmt om denne typer porter som samler et stort antall brukere av en inhouse programvareleverandør i en trusted user group. I følge WebMethods, benytter www.mysap.com deres programvare.

Jus og DTD’er & Schemas

Introduksjon

Ved B2B ehandel er en helt avhengig av å ha felles forståelse av data som utveksles. I XML verdenen gjøres dette ved at partnere blir enig om de DTD’er eller Schema som alle utvekslinger skal være i henhold til. Når en handelstransaksjon utføres vil strukturen i de data som utveksles være i henhold til gjeldende DTD evt. Schema. Antall aktører som benytter samme DTD evt. samme Schema vil utgjøre den gruppen av aktører som uten videre konverteringer kan utveksle data med hverandre på maskin til maskin basis. Det er en stort fordel for f.eks. ebXML at flest mulig aktører benytter deres DTD’er /Schema. De ønsker selvsagt full kontroll på utviklingen av disse DTD’ene/Schemaene, hvis ikke vil en fort få øyer/grupperinger av aktører som utveksler data som nesten er kompatible.

Problemstilling

DTD’er og Schemas vil høyst trolig ikke komme inn under copyright av "intellectual property" iht. amerikansk lov, i følge professor Pamela Samuelson, University of California at Berkeley. Sjansen for at Norsk eller andre europeiske lands lover om opphavsrett vil gjelde for DTD’er og Schemas, er enda mindre enn for amerikansk lov (ref. Pamela). Dette er knyttet til at det i europeisk lovgivning er vanskeligere å oppnå copyright beskyttelse enn i amerikansk lovgivning.

Hvis amerikansk copyright skulle vise seg å gjelde for større og kompliserte Schemas vil det allikevel være mulig å benytte deler av et Schema, eller bruke et Schema som er endret, selv om endringen ikke er vesentlig. Dette vil gjelde selv om forfatter av Schemaet påberoper seg copyright. Å benytte et Schema i sin opprinnelige form som en del av at større skjema vil således også ligge utenfor det en kan påberope seg copyright på (ref Pamela).

Dette er jus-smakebiter for initiativer som BizTalk, ebXML m.fl.

(Problemstillingen er sent til IRI for kommentar, svaret legges trolig ut her så snart jeg får det.)

Jump start, eller Jstart

Nå tilbyr de fleste ehandel aktørene Jump start løsninger.
Da er det vel bare å hoppe i vei da…. J

Interoperabilitet mm.

Nå som det meste skal kunne gjøres ved å bruke XML som syntaks, hva da med sammenhengen mellom XML og resten av XML familien. Sett at jeg sender fra meg et XML dokument som benytter seg av XSL, CSS og XSLT. Har jeg da noen mulighet for å forsikre meg om at mottaker sin applikasjon håndterer helheten slik som avsender forutsatte. Støtter mottaker applikasjon de samme versjoner av XSL, CSS og XSLT som avsender forventer. Hvis mottagers applikasjon ikke støtter helheten, skal applikasjonen da unnlate å vise innholdet i dokumentet eller skal applikasjonen gjøre så godt den kan?

Hva vil det si å støtte DOM? Kan en browser sies å støtte DOM når redigering/endring av et XML dokumentet via DOM ikke er implementert, men kun lesing og traversering i trestrukturen er det?

Det ble foreslått at det som en del av namespace bør ligge informasjon om hvordan f.eks. CML (Chemical Markup Language) skal presenteres. Hva om namespace faktisk kunne brukes til å peke til en applet som skulle kunne presentere innholdet i f.eks. et CML dokument, MathML dokument osv. Da ville vi kunne utveksle data fra mange fagfelt uten at mottaker skal på forhånd ha lagt inn en gitt plug-in el.

Sett at Excel lagrer i rent XML format, skal en kunne ta dette "Excel" dokumentet opp i en XML editor og jobbe videre med som et regnark? Hva vil det egentlig si at en editor er en XML editor? Spørsmålet blir spesielt interessant når en ser for seg mange typer data som struktureres og lagres i XML syntaks. Vil det være hensiktsmessig å ha en editor som kan håndtere MathML, CML. "Excel" og vanlig tekst? Neppe.

Det gjenstår ennå en god del arbeid før en får løst mange av de grunnleggende interoperabilitet problemene. Selv om en får utvekslet data, så har en fremdeles vanskeligheter med å få presentert data på en hensiktsmessig måte. Og enda større vansker har en med å med å få data utvekslet og integrert semantisk i interne logistikksystemer.

</Reisebrev fra XML 99>