DSIT 2012 - konklusionen

Baggrund: I 2007 deltog CIBER første gang i en interoperabilitetstest af ODF og OOXML - dengang foranlediget af det daværende ITST. Vi deltog sammen med en række andre nøglespillere i det nogen dengang kaldte "Dokumentformatkrigen". Disse var IBM, CIBER, Novell, Sun og Magenta. Siden har vi gentaget disse interoperabilitetstests nogle gange - hver med sit fokusområde.

I slutningen af 2012 fik vi afsluttet vores interoperabilitetstest af rundsending af dokumenter, der indgik i en redigeringsproces. Det var en længere seance, hvor forarbejdet reelt startede helt tilbage i sommeren 2012, hvor vi gjorde os de første konkrete tanker om, hvordan vi skulle strukturere testen.

Den visuelle repræsentation af resultaterne var som dette:

Som det ses er resultatet overordnet set relativt trist - omend hvis man bruger OOXML som rundsendingsformat er resultaterne lidt bedre end hvis man havde valgt at bruge ODF som dokumentformat. Der er 100% interoperabilitet i ét tilfælde, nemlig imellem Microsoft Office 2007 og Microsoft Office 2010 (det er måske ikke så overraskende), men selv hvis dette tilfælde fjernes, så har Textmaker bedre understøttelse af OOXML end af ODF. Det er svært for os at konkludere noget specifikt omkring selve årsagen til dette, men det synes at bekræfte en tendens til, at understøttelsen af OOXML i markedet generelt er for opadgående, hvorimod den for ODFs vedkommende er (pænt sagt) i stagnation. Et par ting er det dog muligt at konkludere: Langt de fleste af fejlene skyldes information i dokumenterne, der rent faktisk forsvinder i processen. Men der er også nogle fejl, der skyldes manglende funktionalitet i dokumentformaterne. ODF understøtter ikke ændringsmarkering af sletning af rækker i en tabel, så dokumenter med tabeller i, der redigeres, vil altid medføre fejl, hvis man anvender ODF som dokumentformat. Det er dog pudsigt, at den eneste fejl som TextMaker laver ved brug af OOXML er netop manglende understøttelse af markering af ændringer i en tabel - selvom OOXML understøtter dette i sig selv.

Da CIBER i 2007 gik ind i arbejdet med OOXML og ODF i Dansk Standard, var det fra dag 1 med "den lange bane" for øje. Det er klart, at understøttelsen af OOXML i markedet dengang var lille og at selve teksten i standarden kunne forbedres, men det var vores faste overbevisning, at vi kunne bidrage til at rette op på dette og dermed på den lange bane sikre så god interoperabilitet imellem kontorpakker som muligt. Det vores test her indikerer er, at vi gjorde det rigtige dengang - i forhold til at sidde på vores hænder og afvente andres handlinger. I hvert fald er understøttelsen af OOXML i markedet markant bedre i dag end den var for bare et par år siden.

(at der er tekniske årsager til, at OOXML i sig selv vil være en bedre basis for interoperabilitet imellem kontorpakker end ODF er en anden diskussion)

Ret beset er konklusionen af ovenstående test desværre, at man ikke skal forvente den store succes med interoperabilitet imellem kontorpakker, hvis man påberegner at rundesende og redigere i dokumenterne. Vores test viser, at for de dokumenter vi anvendte, så er kvaliteten i interoperabiliteten større for OOXML-filerne end for ODF-filerne, men det er altsammen forskellige nuancer af "ret dårligt" - desværre. Derfor må man gøre sig det klart, under hvilke forudsætninger man ønsker at udsende

Hvorfor interesserer CIBER sig overhovedet for dette?

I de virksomheder vi arbejder i, er den rene implementering af IT-systemer jo kun én del af vores daglige arbejde. Vi bistår også med rådgivning af vores kunders udfordringer, når det synes relevant eller spørgsmålet ligger i omegnen af det vi ellers laver i virksomheden. Så når vi har vores daglige gang hos vores kunder, så bliver vi jo naturligvis spurgt til råds om alt fra problemer med printere til spørgsmål om valg imellem "Castle Windor" eller "Microsoft Unity" til ... ja, hvordan de bruger deres kontorpakker bedst. Jeg antager sådan set, at dette er noget langt de fleste konsulenter vil nikke genkendende til.

I mange af de systemer vi implementerer er "dokumenter" en vigtig del - være det enten systemer, der udspyr tekstdokumenter eller behandler indholdet i dem eller systemer, der genererer regneark eller bruger dem som datainput til finanssystemer, ERP-systemer eller lignende. Kun vores kunders fantasi sætter grænserne for anvendelsen af dem :-). Det er ikke altid de har for øje, at der findes andre kontorpakker derude end den de selv anvender - og her er det jo så vores opgave at sikre, at de dokumenter vores systemer anvender kan bruges af kontorpakkerne på markedet med størst brugerandel. Det er normalt ikke det store problem.

En række af vores kunder er offentlige institutioner af forskellig art, og søreme om ikke de nogle gange laver tekstdokumenter, som de sender rundt i en redigeringsproces. Som I ved er rundt regnet 95% af alle tekstdokumenter, der rundsendes, slet ikke i nærheden af en redigeringsproces - de sendes blot rundt i fx DOCX-format fordi forfatterne af dem ikke kender til "Eksporter som PDF"-funktionen i deres kontorpakke. Men for de sidste 5 procent er det uhyre vigtigt for dem, at modtagerne rent faktisk kan redigere dem og sende dem tilbage - uden at alt går i fisk. Derfor bruger vi tid på det i CIBER - og derfor er denne test værdifuld.

Yderligere undersøgelser

Det siger sig selv, at man ikke kan konkludere på baggrund af vores test, at det ikke er muligt at lave en redigeringsproces, hvor der ikke tabes data - til det er analysen for simpel. Men man kan i hvert fald konkludere, at man ikke kan antage, at processen som udgangspunkt ikke vil være tabsgivende. Og man kan konkludere, at det er farligt at sige, at "hvis bare du bruger format X, så giver det bedst interoperabilitet". Når vi i CIBER mødes at disse udfordringer og spørgsmål hos vores kunder, så laver vi en mere grundig analyse af de dokumenter, som rent faktisk bruges i organisationen. Nogle gange giver det anledning til at konkludere, at kunden ikke behøver at bekymre sig om interoperabilitet og andre gange bliver konklusionen, at med mindre den modtagende part bruger samme kontorpakke som den konkrete kunde, så mistes information i processen.

Én ting er i hvert fald sikkert - hvis du uden at blinke blot anbefaler din kunde at bruge "program x", for "så får I ingen problemer" - så gør du din kunde en bjørnetjeneste. Du er nødt til at undersøge det nærmere.

Jesper Lund Stocholms billede
Jesper er seniorarkitekt hos projectum Aps i Værløse og arbejder med PPM-løsninger baseret på Microsoft Project Online. Jesper blogger om softwareudvikling og IT-politik

Kommentarer (12)

Kristoffer Olsen

Interessant. Men nu hvor Office 2013 er ude, bør man vel gentage testen med brug af OOXML-Strict eller hvordan?

Jesper Lund Stocholm

Interessant. Men nu hvor Office 2013 er ude, bør man vel gentage testen med brug af OOXML-Strict eller hvordan?


Det vil mig bekendt ikke give nogen voldsom værdi, da LibreOffice ikke understøtter strict og Microsoft Office i versioner tidligere end 2013 ikke kan skrive strict dokumenter.

Det kunne til gengæld være interessant at se på interop via cloud-løsningerne Office365 og Google Docs, så der kommer måske sådan en test lidt senere.

:o)

Kristoffer Olsen

Jeg er ikke inde i detaljerne, men er Strict ikke en delmængde af Transitional eller hvordan? I givet fald burde man vel implicit kunne understøtte Strict, hvis man gør et helhjertet forsøg på at understøtte Transitional?

Aspose skriver i hvert fald "we can regard the Strict as Transitional minus some ECMA-376:2006 features."

Kilde: http://www.aspose.com/blogs/aspose-products/aspose-words-product-family/...

Peter Stricker
Jesper Lund Stocholm

Jeg er ikke inde i detaljerne, men er Strict ikke en delmængde af Transitional eller hvordan? I givet fald burde man vel implicit kunne understøtte Strict, hvis man gør et helhjertet forsøg på at understøtte Transitional?


Det er rigtigt, at den tilladte funktionalitet i Strict er mindre end den tilladte funktionalitet i Transitional, men hvis du ser på repræsentationen af dokumenterne i XML, så er der intet overlap overhovedet - da namespaces i Transitional er anderledes end namespaces i Strict. Denne "breaking change" var et meget bevidst valg vi foretog i arbejdsgruppen i ISO.

Med andre ord: hvis din app understøtter Transitional, så er det på ingen måde det samme som at man understøtter Strict. Man kan naturligvis i sin app tilføje namespaces for Strict og så indlæse disse dokumenter som var de Transitional dokumenter, men det er noget man aktivt skal gøre - det kommer ikke af sig selv.

I øvrigt er det lidt en misforståelse at opfatte Strict som

"Strict = Transitional minus noget_gammelt"

Reelt er det omvendt - nemlig at

"Transitional = Strict plus noget_gammelt"

Kristoffer Olsen

men hvis du ser på repræsentationen af dokumenterne i XML, så er der intet overlap overhovedet - da namespaces i Transitional er anderledes end namespaces i Strict. Denne "breaking change" var et meget bevidst valg vi foretog i arbejdsgruppen i ISO.


Tak for forklaringen omkring forskellige namespaces. Den havde jeg ikke lige fanget, men det giver jo god mening også i forhold til hvorfor der er OOXML-Strict understøttelse i Office 2013 men ikke i 2011, 2010, 2008 eller 2007.

Jeg kommer uvilkårligt til at spekulere på, om man eventuelt har udnyttet denne "breaking change" i Strict som anledning til at harmonisere navnene for de samme egenskaber på tværs af dokumenttyper? Som jeg husker det, var de forskelligeartede navne for de samme attributer et af de mere kosmetiske kritikpunkter, som i sin tid blev fremført i relation til OOXML-standardens læsbarhed?

http://www.robweir.com/blog/2008/03/disharmony-of-ooxml.html

Peter Stricker

Hvordan kan Part 4 være et eksempel på EEE?


Part 1 til 3 definerer dele, som det er væsentligt at have med i et dokumentformat. Part 4 definerer dele, der ikke er nødvendige i et dokumentformat, men kun er med af hensyn til bagudkompatibilitet med ældre udgaver af Microsoft Office.

Det ville være langt nemmere at lave alternative implementeringer af office programmer, såfremt disse kun skulle dække part 1 til 3 og kunne undlade at bruge kræfter på part 4.

Men da den største spiller på markedet for kontorprogrammer (endnu?) ikke bruger Strict som sit standardformat, så bliver alternative kontorprogrammer nødt til at implementere understøttelse for alle 4 parts for at have kompatibilitet med Microsoft Office.

Med OOXML Part 1 til 3 embracer Microsoft dokumentinteroperabilitet, med Part 4 extender de det i et forsøg på, om ikke at extinguish konkurrenter, så i det mindste at holde dem nede.

Peter Stricker

I øvrigt er det lidt en misforståelse at opfatte Strict som

"Strict = Transitional minus noget_gammelt"

Reelt er det omvendt - nemlig at

"Transitional = Strict plus noget_gammelt"


Bortset fra, at den eneste forskel på de to ligninger er semantisk, så vil jeg give dig ret i, at Transitional burde være = "Det der er brug for" plus "noget ligegyldigt legacy".

Men du ved jo udemærket godt, at den øverste version er den, der afspejler virkeligheden.

Hovedformålet med OOXML var, at lave et dokumentformat, der understøttede den fulde funktionalitet i de gamle versioner af Microsoft Office. Opdelingen i Strict og Transitional var udelukkende et strategisk træk, der skulle lukke kæften på modstanderne.

Jesper Lund Stocholm

Tak for forklaringen omkring forskellige namespaces. Den havde jeg ikke lige fanget, men det giver jo god mening også i forhold til hvorfor der er OOXML-Strict understøttelse i Office 2013 men ikke i 2011, 2010, 2008 eller 2007.


Mjaeh ... teknisk set er der ikke noget i vejen for at understøtte disse ting i tidligere versioner af Microsoft Office - jeg tror dog mere, at det handler om at Microsoft er ekstremt tilbageholdende med at gå tilbage og åbne kildekoden til allerede frigivne programmer op.

Jeg kommer uvilkårligt til at spekulere på, om man eventuelt har udnyttet denne "breaking change" i Strict som anledning til at harmonisere navnene for de samme egenskaber på tværs af dokumenttyper?


Det gjorde vi ikke, nej. Som du selv siger det, så er det en kosmetisk ting, og vi har prioriteret andre ting højere.

Jesper Lund Stocholm

Med OOXML Part 1 til 3 embracer Microsoft dokumentinteroperabilitet, med Part 4 extender de det i et forsøg på, om ikke at extinguish konkurrenter, så i det mindste at holde dem nede.


Kan du ikke forklare mig, hvilke dele af Part 4, der ikke fra første dag har været understøttet i konkurrenterne til Microsoft Office?

Du udtaler dig tydeligvist om noget, som du klart ikke har nogen som helst forstand på.

Hovedformålet med OOXML var, at lave et dokumentformat, der understøttede den fulde funktionalitet i de gamle versioner af Microsoft Office. Opdelingen i Strict og Transitional var udelukkende et strategisk træk, der skulle lukke kæften på modstanderne.


Undskyld, men hvem tror du ønske S/T-opsplitningen? Hvem tror du fandt på udskiftningen af namespaces i Strict?

Log ind eller opret en konto for at skrive kommentarer

IT Businesses