Jeg har i den seneste tid været lidt ophængt med planlægning af aktiviteter – herunder booking af arrangementer for mit kommende arkitektforum og har ikke fået blogget meget. Jeg skylder nogle posts, og hvad er mere naturligt nu da sommerro’en snart sænker sig over det åbne kontorlandskab.

Jeg slæber rundt på noget gammelt legacyviden fra før mit engagement med Microsoft, hvilket betød, at jeg følte mig enddog særdeles truffet da John Gøtze lavede et indlæg på Ingeniøren omkring OASIS Open Document Format (ODF) og Office OpenXML. John henvendte sig blandt andet specifikt til gamle ex-kollegaer fra IT- og Telestyrelsen og Microsoft lobbyister (min udlægning) – jeg kvalificerer vist til den fællesmængde.

Jeg er en stor fan af Johns skrivestil og vil i al ydmyghed forsøge at samle bolden op. Det betyder dog ikke, at jeg kan indgå i en større dialog (læs: dette falder lidt uden for mit daglige ansvars område! – jeg er i virkeligheden ikke lobbyist!).

Her vil jeg tilbyde at rette lidt på de resultater John er kommet frem til

Åbenhed

John skriver, at OASIS er en mere åben standardiseringsorganisation end ECMA. De mål, som bliver scoret på denne konto, vil jeg gerne underkende. Jeg har selv en del indblik i OASIS arbejde og har arbejdet i en af OASIS’ TC’erne, samtidigt har jeg indblik i en del ECMA arbejde – en af mine venner er formand for TC 45. Jeg mener ikke, at der er begrundelser for at se den ene organisation som mere eller mindre åben end den anden.

Der er i øvrigt noget, der har naget mig på det seneste. John beskriver ODF, som en ”fuldstændigt åben standard” – jeg vil på ingen måde stille spørgsmålstegn ved dette. Jeg er dog undrende overfor den differentiering af åbne standarder, der finder sted pt (ikke kun fra Johns side!) med tillægsord, som ”reelt”, ”rigtig” og nu ”fuldstændig”.

Modenhed

Jeg kan ikke gøre indsigelser på Johns resultat udfra de målepunkter han har. Jeg vil dog stille spørgsmålstegn ved det hensigtsmæssige i ensidigt at kigge på ratificering og produktunderstøttelse som målepunkter, uden også at kigge på produkt- og formatudbredelse, samt standardens historik.

Hvis jeg , som John opfordrer til, skal lave et indspil til politikere og embedsmænd i præciseringen af B103 og OIO-kataloget på dette område må det være, at formuleringen af tiltagene i B103 g OIO Kataloget fokuserer mere på at gøre forretningsløsninger og -infrastruktur åbne end rigidt at stille sig fast på principielle beslutninger om enkelte standarder. Hvilket i øvrigt er meget nemt at komme til at gøre med en ”liste” af standarder, som OIO-kataloget er.

Interoperabilitet

Jeg kan i min vildeste fantasi ikke se, hvordan ODF er mere interoperabelt end OOXML! Hvor bliver de mål scoret? Er de XML tags, som er i ODF bedre ”formuleret” og beskrevet end de, som er i OOXML. Hvorvidt det ene format er mere interoperabel må ideelt set bero på noget mere håndfast. Som tingene er i dag, mener jeg, at graden af interoperabilitet kun udtrykkes ud fra en subjektiv vurdering af den udvikler, som sættes til at lave en konvertering mellem de to standarder.

...og dog - hvis man skal til at kigge nærmere på dette område så kunne man f.eks se på, hvilke elementer i de to formater, som ikke er repræsenteret som traditionel tekstbaserede content i xml tags. Det kunne være grafik, animation .... eller formler f.eks i regneark. Mig bekendt er der ikke standarder for formler til f.eks regneark – det må naturligvis betyde at det format med bedst formel-funktionalitets-understøttelse er det mindst interoperable. Her er det mit gæt, at OOXML har mere formelunderstøttelse og er dermed mindre interoperabelt end ODF.

Udbredelse

ODF er en ratificeret ”dokument” standard – det er OOXML ikke. ODF er en ratificeret ”dokument” standard – det er PDF ikke. ODF er en ratificeret ”dokument” standard – det er XXXX ikke. Denne kamp vil ODF jo i sagens natur vinde, som tingenes tilstand er pt. – ODF er det eneste hold på banen. I et forretningsmæssigt perspektiv bliver denne kamp meningsløs. Hvis man kan se på et udbredelseskriterie udfra om formatet er en ratificeret standard skal man pt vælge ODF. Hvis man derimod også i sin forretning er tynget af at skulle være bagudkompatibel, interoperabel med andre formater og platforme og integrere til backend applikationer med krav om fortrolighed, uafvislighed og persistens, så ville jeg personligt kigge på alternativer til ODF.

Egnethed

Omkring egnethed sår John tvivl om OOXML’s muligheder i forhold til at bruge andre XML vokabularier (min udlægning! Set mig straight hvis jeg er på afveje her!). Jeg kan godt forstå denne udlægning og anerkender at ODF har gået meget langt for at bruge andre standarder, hvor det er muligt. John nævner 3 områder, som jeg vil kommentere på.

Dublin Core: ODF bruger metadata formatet Dublin Core – det samme gør OOXML! Ydermere kan begge formater derudover tilbyde understøttelse for alle de metadataformater brugerne vil kunne finde på. Derudover vil OOXML have en applikation i ryggen, som rent faktisk understøtter, at brugerne kan kombinere dokumentformatet med et hvilket, som helst xml baseret forretningsvokabularie, for eksempel UBL.

Johns promo af ODF på dette område, tror jeg går mere på, at ODF plukker fra andre standarder til at løse specifikke problemstillinger i dokumentformatet. Hvis man tager et område som grafik (f.eks ”clip art” eller lignende ting) et dette, så vidt jeg ved, specificeret i en delmængde af den standard, som hedder Scalable Vector Graphics (SVG) i ODF. SVG er en W3C recommondation, mens det tilsvarende i OOXML er specificeret i Vector Markup Language (VML), som i sin tid ”kun” blev publiceret som en W3C note.

I forhold til overvejelser vedrørende B103 og OIO-katalog bliver tingene nu en anelse spegede. Nu skal man bruge et vurderingskriterie, som tager stilling til om det er ”bedst” i egnethedsmæssig forstand - at bruge en mindre delmægde af en ratificeret standard (SVG som brugt i ODF) eller om man skal holde sig til en specifikation, der er en 10 år gammel note, som først nu undergår formel standardisering, men som er blevet brugt i flere år i produktion (VML som brugt i OOXML).

En diskussion omkring grafik, som denne bringer mig videre til et punkt om scope. For at sammenligne ODF og OOXML – grafik, som SVG og VML, er man måske i grænselandet for, hvad der kan siges at være traditionel kontor applikationsfunktionalitet – som åbenbart (jeg ved ikke, hvem der sætter den slags scopes!) er sat til at være format for tekstbehandling, regneark og præsentationsapplikationer. Personligt glæder det mig, at John udvider (fodbold?)banen ved mene at elektroniske formularer (Xforms) også bør være en del af denne disskussion. Det kan nemlig hjælpe mig med at perspektivere og give lidt baggrund til politikere og embedsmænd.

I en nyhedsudsendelse var der for nylig et indslag omkring sagsbehandleres manglende tid med klienter på arbejdsløshedformidlingen i Nakskov. I indslaget blev der generaliseret for området, så det ikke kun var et isoleret Nakskovproblem. Vinklen på indslaget var at to trediedele af sagsbehandlerens tid gik med at indtaste data i systemer - dvs. traditionelt kontor arbejde for den sagsbehandlende - og kun entrediedel gik på samtaler og face2face med de arbejdsløse klienter. Indslaget listede de ting en sagsbehandler brugte af værktøjer i deres kontorarbejde og så vidt jeg kunne se, var der ikke på noget tidspunkt tale om tekstbehandling, regneark eller præsentationsprogrammer – det var alt sammen formularbaseret input. Jeg vil ikke konkludere noget generelt på denne baggrund blot konstatere, at min erfaring siger mig, at formularbaseret frontends har en stor plads i dagligt kontorarbejde i mange brancher.

I ODF-regi betyder dette formentlig i praksis, at nogle applikationer, som benytter ODF også vil vælge at understøtte Xforms. I september 2005 var jeg f.eks. til en SUN-demo af en betaimplementering af Xform 1.0 (den specifikation, som blev udskiftet i marts 2006 med en second edition) i StarOffice. ODFs brug af Xforms ”inden i” formatet er igen baseret på et lille subset af hele Xforms specificationen.

Der ligger gode muligheder for ODF og venter, hvis man en dag får en fuld implementering. Jeg mener at mulighederne venter, fordi der er forretning i at have et generisk formularværktøj til kontorpersonale. Men, selv hvis ODF en dag får hele Xforms ind i standarden og en applikation kan lave denne understøttelse, så vil der stadig være en række forretningskrav ODF ikke kan honorere – simpelthen fordi det mangler at blive implementeret i Xforms standarden.

Infopath applikationen i Microsoft Office har siden 2003 kunnet lave brugerdefinerede xml-strukturer – både åbne standarder eller lukkede - og digitalt signere og co-signere hele eller udvalgte dele af formularer. Infopath supporterer ikke Xforms. Standarden var der simpelthen ikke, da produktet blev udviklet. Formularer bliver lavet i et xml vokabularie ved navn infopath form templates (.xsn), formularerne benytter sig af W3C Xml Schema til strukturer og man kan signerere formularer ved hjælp af certifikater som overholder X.509 v3 standarden. Jeg mener at Microsoft gik meget langt for at ”overholde” alle de gængse standarder, som var i markedet under udviklingen af Infopath.

Set i perspektivet af B103 og OIO-kataloget giver dette mig lidt grå hår. Muligvis er jeg bare for konservativ i min udlægning af teksten, men her er mit input. Efter 1. Januar 2008, når arbejdsformidlingen skal udskifte/have nye formularbaserede indtastningssystemer, tvinges de offentlige IT-chefer til at købe Xforms-baserede systemer, som ikke har OCES understøttelse og fravælge Infopath-lignenede systemer, fordi præsentationsdelen af applikationen (selv om den er åbent dokumenteret og fri for royalty) ikke er standardiseret i et standardiseringsorgan? I min optik vil det være et teknologisk og forretningsmæssigt tilbageskridt på minimum 5 år.

Potentiale

Jeg er en stor fan af innovativ udvikling i software og forventer ikke, at mange er uenige i det. Derfor er det med glæde, at jeg går på arbejde hver dag og ser, hvordan min arbejdsgiver i alt, hvad de foretager sig af nyudvikling baserer dette på standarder, som alle kan få adgang til på lige vilkår, og herved forsøger at være med til at sætte dagsordenen. Microsoft forsøger endda nogle gange, at imitere græsrødder for at få en ny spec adopteret. Jeg har ikke de store forventninger til f.eks SSE - simpelthen fordi jeg tror at græsrødderne forkaster SSE. Jeg håber dog, at vi hos Microsoft ikke forkaster de ideer, der ligger bag SSE, men istedet implementerer det i produkter.

Vi forsøger at realisere vores softwarepotentiale (det er da vist taget fra en reklame!??!?) ved at bruge teknologi, som er åben og let tilgængelig for alle. Men i forsøget på at være innovative og sætte en ny dagsorden har man til tider brug for teknologi, der simpelthen ikke er en standard for. Andre gange vælger man en standard/teknologi, som ikke ligger tæt op ad det, markedets andre spiller brugere, fordi det på længere sigt virker som det rigtige at gøre. Jeg har fuld sympati for at ODF folkene i OASIS har valgt at bruge Relax NG standarden til at udtrykke ODF i . Dette har de gjort til trods for, at langt størstedelen af softwaremarkedet vælger W3C Xml Schema til at lave dokumenttypedefinitioner i. Faktisk bliver langt de fleste xml-standarder i ODF’s søster OASIS TC’ere skrevet i W3C Xml Schema, men ODF TC’en har formentlig valgt Relax NG fordi det passede på netop de krav de havde til et definitionssprog uden at skele til, hvad der er kutyme eller hvad andre bruger.

Til sidst vil jeg slutte med at sige, at jeg ikke tror på en ”en standard til at herske over dem alle”-politik og håber virkelig at politikere og embedsmænd vil gøre sig helt klart, hvad det egentlig er, man vil have ud af disse tiltag. Det er mit håb, at en sådan principiel beslutning, som B 103 er, ikke vil give anledning til at udforme IT-systemer begrænset af en statisk liste formuleret i et katalog. Personligt vil jeg synes, at det er uheldigt, hvis B103 betyder at komponenter, som f.eks. dokumenter i PDF formatet, kode skrevet i programmeringssproget Java og nyhedsindlæg skrevet i xml vokabulariet RSS vil være diskvalificeret i statens IT systemer efter 1. Januar 2008. Jeg tror, at det er forkert at hensynet til åbne standarder, som det er formuleret i B103, kan udelukke en bestemt teknologi. IT systemer i både det offentlige og private bør udarbejdes/indkøbes ud fra de 5 Hvidbogsprincipper, revisionen af eksisterende processorer og opdrivelsen af nye forretningsmuligheder. Jeg håber, at hensyn til ovenstående kan adresseres når Videnskabsministeriets embedsmænd skal ”fill-out-the-blanks” på B103.

John: Det må du gerne tage med videre fra mig.

PS. Dette blogindlæg er skrevet og postet fra en OOXML reference implementering – Word 2007 og ja, den kan også poste til Wordpress ;-)