Jesper Lund Stocholm bloghoved

Den stooore Interoperabilitetstest 2012 (DSIT 2012)

Indledning

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 og Magenta. Siden har vi gentaget disse interoperabilitetstests nogle gange - hver med sit fokusområde.

Nu hvor året går på hæld er det tid til afviklingen af et kært barn - nemlig "Den store Interoperabilitetstest".

Denne gang har det været vigtigt for os at skubbe grænsen en smule mere i en "realistisk" retning end det har været tilfældet tidligere. De tidligere gange har vi testet simple "load-tests", dvs undersøgt hvordan et dokument så ud, når det blev åbnet i forskellige kontorpakker.

Afsættet har altid været det såkaldte B103-forslag, der som bekendt skabte rammen omkring nogle retningslinier for anvendelse af åbne standarder i (den offentlige sektor i) Danmark. Heri stod der ibland andet, at ikke-redigerbare dokumenter skulle udveksles i den åbne standard PDF/A og at redigerbare dokumenter skulle udveksles i de åbne standarder ODF og/eller OOXML.

Udfordringen denne gang har været, at vi længe har været lidt utilfredse med forløbet af vores interoperabilitetstests, for hvis vi snakker om ODF og OOXML, så er vi også nødt til at snakke redigerbare dokumenter - og dermed dokumenter, der indgår i en redigeringsproces. Og det viser en simpel load-test intet om.

Arbejdet startede allerede foråret og lad det være sagt med det samme - vi kom til at slå for stort et brød op. Som nogen måske kan huske, så efterlyste vi input til kandidater (kontorpakker) til testen, og vi endte med en 5-10 kontorpakker, som det kunne være interessant at kigge på. Alene antallet gav jo i omegnen af 100 individuelle tests vi skulle afvikle, men vi gik fortrøstningsfuldt i gang. For at skabe en fælles basis, anvendte vi dokumenterne fra ITSTs "Test-selv pakke".

Vi måtte dog hurtigt erkende, at ikke alene var 100 tests et stort antal - kompleksiteten af analysearbejdet blev voldsomt stor. For selvom dokumenterne i teorien er dokumenter man ville forvente at finde i en tilfældig kommune, så viste det sig, at bare det at indlæse dem i programmerne voldte problemer. Nogle programmer ødelagde simpelthen indholdet i dokumenterne så meget, at en videre test blev ligegyldig. For hvis information var forsvundet alene ved indlæsning af dokumentet, hvad ville værdien så være i at teste hvordan dette ødelagte dokument så ud efter at være redigeret af et andet program?

Derfor måtte vi i efteråret tilbage til tegnebrædtet og designe en ny test.

Vi vil derfor teste følgende scenarie:

En kommune bruger kontorpakke X og indgår i en dialog med en anden kommune omkring dokumenter, der rundsendes og redigeres løbende

Dette er på ingen måde noget urealistisk scenarie - ja faktisk sker dette hver dag rundt omkring i kommunerne.

Vi har gjort følgende:

  • Vi har lavet dokumenter i ODF og OOXML, der er typiske for en offentlig organisation. De indeholder billeder (logo), afsnit, margins, tabeller, dynamiske felter (ex "Side X af Y") og lidt typografi. Med andre ord - ikke voldsomt avancerede dokumenter.
  • Dokumenterne "sendes" til en anden kommune, hvor der rettes i dem og de sendes retur
  • Dokumenterne testes i de tre trin for om al information i dokumenterne er bevaret samt om informationer om ændringer korrekt sendes med dokumentet, så de kan "godkendes" af den oprindelige afsender, når de kommer retur.

Processerne tildeles i hvert skridt et "trafiklys" som vi har gjort tidligere. Vurderingen sker således:

FarveKriterier for opfyldelse
GrønAl information er bevaret og alle ændringer i dokumentet er persisteret korrekt. Alt behøver ikke at være "pixel-perfekt", så små ændringer i layoutet accepteres
GulAl information er bevaret og alle ændringer i dokumentet er persisteret korrekt. Men layout af dokumentet er blevet så rodet, at det kan forstyrre forståelsen af dokumentet
RødInformation er gået tabt undervejs

I hverdagsformulering siger disse krav dermed, at information ikke må gå tabt men at der dog er en hvis overbærenhed med layoutet af dokumentet (hvis der ikke var denne tolerance, så var ODF og OOXML i øvrigt et forkert valg i den konkrete proces).

Da vi ikke ønsker en akademisk øvelse (igen) har vi testet tingene i kontorpakker med en hvis modenhed, som vi med rimelighed forventer en kommune ville kunne vælge som fælles platform. Disse er dermed:

  • Microsoft Office 2007
  • Microsoft Office 2010
  • LibreOffice
  • Textmaker

Alle dokumenter bliver naturligvis gjort tilgængelige, så I er velkomne til selv at fortsætte, men vi vil ikke teste flere kontorpakker for nuværende.

Stay tuned ...

Kommentarer (9)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
ab ab

Textmaker

Dejligt at se, at du stadig har TextMaker med i din sammenligning. Programpakken er efter min mening kommet rigtig godt efter det de seneste år ikke mindst på interoperabilitetsfronten. Må man spørge hvilken version, du påtænker at teste mod?

Det er måske værd at bemærke, at SoftMaker i juledagene kører en kampagne, hvor man kan downloade en gratis udgave af deres kontorsuite og samtidig støtte et velgørende formål. Den såkaldte "FreeOffice"-pakkes er tilgængelig til både Windows og Linux og dens eneste begrænsning er mig bekendt, at man ikke kan gemme i DOCX, XLSX og PPTX-formaterne. Man kan imidlertid godt læse disse formater.

Hvad der i mine øjne er endnu mere interessant er, at det er muligt at få såkaldt "upgrade pricing" fra FreeOffice-pakken til den nyeste udgave af SoftMaker Office. Det betyder, at man kan købe hele kontorpakken (inkl. kalender- og mailprogrammet emClientPro) til mellem 30 og 40 euro (afhængig af platform og om emClientPro skal med eller ej):

Download gratis FreeOffice: http://freeoffice.com/
Prisliste for SoftMaker Office-opgraderinger: http://www.softmaker.com/shop/shop.php?go&products

Er det i øvrigt OOXML-Strict, du bruger til at teste interoperabiliteten på dette dokumentformat med?

  • 0
  • 0
Henrik Madsen

Jesper: Jeg synes, at det ville være langt mere interessant at teste interoperabilitet mellem platforme.

For rigtig mange af os på DTU er det ikke særlig interessant mht. succes af flytning mellem Windows og Windows. Derimod er platforme, såsom Android, iOS, Linux, er uhyre populære, og mit forslag til en langt mere nyttig interoperabilitetstest af ODF og OOXML ville være at teste, hvorledes disse dokumentstandarder fungerer, når der tales om flytning mellem ovennævnte meget anvendte og populære platforme.

  • 0
  • 0
ab ab

Derimod er platforme, såsom Android, iOS, Linux, er uhyre populære, og mit forslag til en langt mere nyttig interoperabilitetstest af ODF og OOXML ville være at teste, hvorledes disse dokumentstandarder fungerer, når der tales om flytning mellem ovennævnte meget anvendte og populære platforme.


Såvel TextMaker som LibreOffice er tilgængelig på både Linux og Windows (samt Android i førstnævntes tilfælde). Er der ikke noget med, at den del af kodebasen, som står for fortolkning af dokumentet, er rimeligt ens i de to/tre versioner af samme applikation?

  • 1
  • 0
Jesper Lund Stocholm Blogger

Må man spørge hvilken version, du påtænker at teste mod?


Seneste version - Textmaker 2012. LibreOffice testes også med "seneste version".

Er det i øvrigt OOXML-Strict, du bruger til at teste interoperabiliteten på dette dokumentformat med?


Der er mig bekendt ikke nogen kontorpakker på markedet i dag, der understøtter OOXML Strict, så det vil være lidt svært :-)

  • 0
  • 0
Jesper Lund Stocholm Blogger

Jesper: Jeg synes, at det ville være langt mere interessant at teste interoperabilitet mellem platforme.


Hvorfor det? Er det da et problem?

mit forslag til en langt mere nyttig interoperabilitetstest af ODF og OOXML ville være at teste, hvorledes disse dokumentstandarder fungerer, når der tales om flytning mellem ovennævnte meget anvendte og populære platforme.


Nu har jeg gået i dag og tænkt over, hvad årsagen skulle være til at fokusere på platforme og ikke applikationer, og jeg kan ikke finde ud af det. Jeg kan simpelthen ikke huske, at jeg nogensinde har hørt om problemer med interoperabilitet ifbm ODF og OOXML, der skyldtes platformsspecifikke årsager. Derfor har jeg rigtigt svært ved at se, hvilken værdi det skulle bibringe en test.

Hvis du kan give mig nogle eksempler på problemer ifht platformsvalget - i den virkelige verden, vel at mærke, så vil jeg gerne overveje det igen. Ellers synes jeg, at det er spild af tid at teste noget som ingen nogensinde har oplevet skulle være et problem. Når man tænker på udfordringerne ved brug af applikationerne selv, så er den imaginære problemstilling omkring platforme så ligegyldig, at det skriger til himlen.

Alternativt kan du jo selv lave testen. Selve testarbejdet er bestemt ikke raketvidenskab, så det skulle du nok kunne finde ud af.

  • 0
  • 0
Jesper Lund Stocholm Blogger

Okay, jeg var ikke klar over, at det var Transitional og ikke Strict, som var implementeret i TextMaker og LibreOffice.


Jeg ved det faktisk ikke mht TextMaker, men LibreOffice har implementeret Transitional.

Vil det sige, at den udgave af Office 2013, som leveres på Surface RT, ikke understøtter Strict?


Øh, det ved jeg faktisk ikke - men Office 2013 er ikke til salg endnu, så derfor er den ikke med i testen.

  • 1
  • 0
Log ind eller Opret konto for at kommentere