Jesper Lund Stocholm bloghoved

OOXML Strict smoke test

Som nogle af jer kan huske, var der engang noget nogen kaldte en "dokumentformatkrig". Det var ikke en "krig" som sådan - det var mere en verbal krig på ord. Disse skrivebordskrige har jo den fordel, at man kan skifte angrebsflade uden omkostninger. Det er samme mekanik man finder i spil som "Risk" og lignende. Man kan omkostningsfrit skifte angrebspunkt og verden står mere eller mindre stille de andre steder imens man flytter fokus. Samtidig kan man også omkostningsfrit skifte våben - der skal ikke en række lastbiler eller fly med nye våben frem før det kan lade sig gøre.

Sådan var det præcist i dokumentformatkrigen.

  • Først blev OOXML kritiseret og invalideret alene af den grund, at den ikke var en ISO-standard. Det blev den jo senere, men på det tidspunkt var det åbenbart overhovedet ikke relevant længere - for man kunne slet ikke stole på ISO til at begynde med, lød det.
  • Så blev OOXML kritiseret fordi den var for lang. Det var et argument, der ikke rigtigt slog igennem - altså hvis man ikke selv blindt troede fuldt og fast på det.
  • Dernæst blev OOXML kritiseret for at den var for dårligt skrevet, men det slog lissom heller ikke rigtigt igennem da det eksisterende alternativ bestemt heller ikke var skrevet af Guds egen, ufejlbarlige hånd.
  • Dernæst blev OOXML kritiseret for at kun Microsoft kunne implementere det, men kritikken blev ligegyldig, da den blev opretholdt selvom de få ting, hvor det rent faktisk var tilfældet, blev fjernet under ISO-behandlingen.
  • Endelig blev OOXML kritiseret for at den version, der var blevet implementeret i markedet var OOXML T (Transitional), og den kunne man bestemt ikke bruge til noget ... selvom det var den alle implementerede.
  • Og til slut blev OOXML kritiseret fordi man nu pludseligt ikke kunne bruge andet end OOXML S (Strict), for det var den eneste alle kunne implementere (ok - det var måske lidt min skyld også) ... selvom ingen, nogensinde, nogensteder havde ønsket det ... altså lige bortset fra skrivebordsgeneralerne på debatfora rundt omkring i verden.

Og hvor er vi så nu? Jo, nu har Microsoft sendt første skud på stammen af sin nye kontorpakke på gaden (eller, til beta-download), og den indeholder søreme skrive/gemme-mulighed for OOXML Strict. Så jeg har lavet en lille test af, hvordan interop med andre kontorpakker end Microsoft Office 2013 er pt.

Hvad gjorde jeg?

Jeg lavede to Hello-world dokumenter i Office 2013 - et tekstdokument og et regneark. Jeg forsøgte herefter at indlæse dem i en række andre kontorpakker. Disse var:

  • Microsoft Office 2007
  • Microsoft Office 2010
  • LibreOffice
  • Apache OpenOffice
  • Textmaker
  • Google Docs
  • Office 365

Jeg har tidligere brugt "Trafiklys-skalaen", så den bruger jeg igen. Grøn betyder "Ingen umiddelbare fejl". Gul betyder "Småfejl men dokumentet kan stadig læses" og Rød betyder "FAIL".

Resultatet var dette:

KontorpakkeTekstdokumentRegneark
Apache OpenOffice
Illustration: Privatfoto

|

Illustration: Privatfoto

LibreOffice |

Illustration: Privatfoto

|

Illustration: Privatfoto

Microsoft Office 2007 |

Illustration: Privatfoto

|

Illustration: Privatfoto

Microsoft Office 2010 |

Illustration: Privatfoto

|

Illustration: Privatfoto

TextMaker |

Illustration: Privatfoto

|

Illustration: Privatfoto

Office 365 |

Illustration: Privatfoto

|

Illustration: Privatfoto

Google Docs |

Illustration: Privatfoto

|

Illustration: Privatfoto

Kort fortalt fejlede alle indlæsning i mere eller mindre katastrofalt omfang. De fleste nægtede pure at åbne dokumenterne (Microsoft Office 2007 og 2010 samt LibreOffice) imens Apache OpenOffice slet ikke reagerede som om den var ved at åbne noget (blanke sider). Textmaker åbnede rent volapyk i tekstdokumentet men kunne fint indlæse regnearket og al information var bevaret.

For sjov lavede jeg den samme test med OOXML-dokumenter i "Transitional"-varianten, og her var resultatet dette:

KontorpakkeTekstdokumentRegneark
Apache OpenOffice
Illustration: Privatfoto

|

Illustration: Privatfoto

LibreOffice |

Illustration: Privatfoto

|

Illustration: Privatfoto

Microsoft Office 2007 |

Illustration: Privatfoto

|

Illustration: Privatfoto

Microsoft Office 2010 |

Illustration: Privatfoto

|

Illustration: Privatfoto

TextMaker |

Illustration: Privatfoto

|

Illustration: Privatfoto

Office 365 |

Illustration: Privatfoto

|

Illustration: Privatfoto

Google Docs |

Illustration: Privatfoto

|

Illustration: Privatfoto

PDF-versioner af dokumenterne kan ses her:

Excel 2013:

Word 2013:

Konklusionen?

Microsoft Office 2013 er stadig i beta-version, så meget kan naturligvis ske endnu. Men jeg er da skuffet over, at den påståede "læsemulighed" for Strict dokumenter i Microsoft Office 2010 ikke er så omfangsrig, som man kunne ønske og forvente.

Som sagt er Microsoft Office 2013 stadig i beta, og der kan naturligvis ske meget inden den endelige version rammer gaden.

Jeg må dog erkende, at jeg er en smule skuffet over resultatet - over en bred kam. Hvis man analyserer indholdet i de to filer, så er der ingen funktionalitet, der ikke allerede nu eksisterer i OOXML. Eneste forskel er dermed reelt XML-namespaces i de konkrete XML-filer. Disse namespaces har været kendt i mindst 2 år, så det ville være en relativt lille rettelse at tilføje de nye namespaces og dermed kunne indlæse eksempelvis de filer jeg har lavet her til denne test. Det er skuffende at ingen at de større kontorpakker på markedet kan indlæse disse filer.

Opdatering 2012-10-06: Jeg har tilføjet Office 365 og Google Docs til testen.

Kommentarer (8)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Peter Stricker

1) At alle har brugt en masse kræfter på at implementere T så godt som muligt, eller
2) At det er meget sværere at implementere S end T, eller
3) At implementeringen af S i Office 2013 er af en ringe kvalitet

Jeg hælder mest til 1. Den dominerende spiller på markedet for Office programmer fortalte, at der ville gå lang tid før de ville implementere ren S. Derfor gav det god mening at lægge flest kræfter her.

3 er også en mulighed. Som du skriver, så er Office 2013 stadig i beta, og det vil være forståeligt, om der stadig er nogle børnesygdomme.

Derimod tror jeg godt, at vi kan afvise 2. Jeg kan på ingen måde forestille mig, at det skulle være sværere at implementere 1 ud af 4 dele af specifikationen, end at implementere alle fire dele.

Hvad mener du selv? Er der en eller flere muligheder, jeg har overset, så kom endelig med dem.

Og så lige et forslag: Du skriver, at du har lavet 'Hello World' dokumenter i Office 2013. Med dit kendskab til OOXML burde det ikke være en uoverskuelig opgave at lave et rent S dokument i hånden (okay, ikke i hånden men i en teksteditor eller en xml editor).

Kan du overtales til at lave et sådant og poste trafiklysresultater for det?

Alternativt kan du også blot bekræfte, at det dokument, der er lavet i Office 2013 har samme indhold, som du ville putte i det, såfremt du havde lavet det i hånden. Det vil være godt nok for mig.

Baldur Norddahl

Eller 4) en overvældende standard på 6000 sider og mangel på test-dokumenter betyder at ingen har haft mulighed for at prøve det. Kode der ikke er testet virker sjældent.

Jeg har implementeret mange systemer ud fra dokumentation der højst var 1% af OOXML og alligevel bliver det aldrig helt rigtigt før man har testet det op imod de andre systemer.

Så det er egentlig ikke super overraskende at vi får et skuffende resultat her. Til gengæld burde det være nemmere at få opgraderet de andre kontopakker til at håndtere strict korrekt. Specielt hvis nogen lige sender dem et notat om problemet.

Jesper Lund Stocholm Blogger

Hej Peter,

Jeg hælder mest til 1. Den dominerende spiller på markedet for Office programmer fortalte, at der ville gå lang tid før de ville implementere ren S. Derfor gav det god mening at lægge flest kræfter her.


Faktisk har Microsoft i flere år fortalt, at Office 2010 havde læse-mulighed for Strict dokumenter, så man har faktisk kunnet interagere med Microsoft Office - også via Strict - siden sidst i 2009. Strict har dog ikke været voldsomt oplagt at implementere, da man funktionalitetsmæssigt allerede stort set dækkede hele indholdet i OOXML T med allerede implementeret funktionalitet fra de binære dokumentformater.

Derimod tror jeg godt, at vi kan afvise 2. Jeg kan på ingen måde forestille mig, at det skulle være sværere at implementere 1 ud af 4 dele af specifikationen, end at implementere alle fire dele.


Husk at

S = 1+2+3
T = 1+2+3+4

Hvad mener du selv? Er der en eller flere muligheder, jeg har overset, så kom endelig med dem.


Helt overordnet set kan man nok ikke konkludere ret meget på andre aktørers handlinger fra mine tests her. Jeg har flere gange forklaret, hvorfor jeg synes OOXML T er det eneste reelle bud på en standard af OOXML-varianterne (og jeg gentager det gerne igen, hvis det skulle have interesse).

Og så lige et forslag: Du skriver, at du har lavet 'Hello World' dokumenter i Office 2013. Med dit kendskab til OOXML burde det ikke være en uoverskuelig opgave at lave et rent S dokument i hånden (okay, ikke i hånden men i en teksteditor eller en xml editor).

Kan du overtales til at lave et sådant og poste trafiklysresultater for det?


Det vil jeg gerne kigge på - god idé.

Vær opmærksom på, at dette er en "smoke test", dvs det er ikke en akademisk øvelse i at se interoperabilitet givet en række specifikke test-detaljer. Det er blot en test af, hvordan interoperabilitet vil være i dag med seneste skud på stammen af de mest populære programmer, der kan læse OOXML.

Alternativt kan du også blot bekræfte, at det dokument, der er lavet i Office 2013 har samme indhold, som du ville putte i det, såfremt du havde lavet det i hånden. Det vil være godt nok for mig.


Som sagt - jeg kigger på det :o).

Jeg har i øvrigt opdateret artiklen med PDF-udgaver af de to dokumenter jeg testede.

Jesper Lund Stocholm Blogger

Eller 4) en overvældende standard på 6000 sider og mangel på test-dokumenter betyder at ingen har haft mulighed for at prøve det. Kode der ikke er testet virker sjældent.


Længden af denne standard er ikke så stort et problem. Anslået 90% af funktionaliteten i OOXML var allerede implementeret i de andre programpakker i form af deres understøttelse af de binære dokumentformater. Eneste store funktionalitetsforskel på de binære dokumentformater og OOXML er reelt DrawingML, dvs det nye grafikformat.

Til gengæld burde det være nemmere at få opgraderet de andre kontopakker til at håndtere strict korrekt. Specielt hvis nogen lige sender dem et notat om problemet.


Det forstår jeg ikke?

Jesper Lund Stocholm Blogger

Det kunne være interessant at teste tingene på forskellige platforme. Det er først her ved det viser sig om formatet kan implementeres. Ideene med et åbent format må være at man ikke binder brugeren til en bestemt applikation eller platform, ellers falder hele ideen til jorden.


Det har du helt ret i. Så da der i OOXML ikke er noget, der binder til nogen applikation eller platform, er der ingen yderligere værdi i at teste på tværs af platforme. Værdien kommer i test på tværs af applikationer.

Til din venlige orientering kan jeg dog fortælle, at testen ovenfor allerede er på tværs af platforme.

Windows:

  • Microsoft Office
  • Textmaker

Mac OS X:

  • Apache OpenOffice

ubuntu 12.04:

  • LibreOffice
Log ind eller Opret konto for at kommentere