ODF/OOXML - rent teknisk rant.
Har brukt litt tid på å se på ODF vs. OOXML i det siste, etter en serie innlegg på Shazad Ranas blogg. Selv sverger jeg vanligvis til LaTeX/LyX, og har fulgt Microsoft sine krumspring mest fra sidelinjen. Men all positive omtalen av OOXML har gjort meg nysgjerrig. Debatten om ODF vs. OOXML har vært kilde til mye kverulering og ordkløyveri. Jeg skal derfor ikke gå veldig i dybden på selve standardene og politikken rundt dette.
Jeg har ramlet over et interessant dokument som tar for seg de to formatene. Det er interessant fordi det tar for seg praktiske eksempler. Det er ikke like tungt som mange andre dokumenter som tar for seg standardene.
Noen vil utvilsomt hevde at jeg er partisk ved å kun ta for meg dette dokumentet, og det kan hende de har rett. Men, dette dokumentet er velskrevet og konsist. Jeg har ikke funnet noe tilsvarende som taler i fordel for OOXML. Opplys meg gjerne.
Så, la oss for et øyeblikk glemme den tunge kranglingen rundt prosedyrer og standarder i ISO og ECMA. La oss heller se på et par praktiske eksempler som tas opp i dokumentet.
Det er interessant å se på eksemplene forfatteren tar for seg. Han tar utgangspunkt i et par eksempeldokumenter og ser nærmere på XML’en som genereres.
Eksempler.
Et kort eksempel i ODF lager følgende XML:
<text:h text:stylename="P1" text:outlinelevel="1">
Example document
</text:h>
<text:p text:stylename="Standard">
This has some
<text:span text:stylename="T1">
bold formatting
</text:span>
, also some
<text:span text:stylename="T2">
with italics
</text:span>
, a
<text:a xlink:type="simple" xlink:href="http://www.odfalliance.com">
<text:span text:stylename="Internet20link">
web link
</text:span>
</text:a>
and a picture...
</text:p>
<text:p text:stylename="Standard">
<draw:frame draw:stylename="fr1" draw:name="graphics1" text:anchortype="aschar"
svg:width="5.9929in" svg:height="5.4362in" draw:zindex="0">
<draw:image xlink:href="Pictures/10000000000002DC00000298CDD44AEF.jpg"
xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad"/>
</draw:frame>
</text:p>
Tilsvarende, generert av OOXML:
<w:p>
<w:pPr>
<w:pStyle w:val="Heading1"/>
</w:pPr>
<w:r>
<w:t>
Example document
</w:t>
</w:r>
</w:p>
<w:p>
<w:r>
<w:t>
This has some
</w:t>
</w:r>
<w:r>
<w:rPr>
<w:b/>
</w:rPr>
<w:t>
bold formatting
</w:t>
</w:r>
<w:r>
<w:t>
, also some
</w:t>
</w:r>
<w:r>
<w:rPr>
<w:i/>
</w:rPr>
<w:t>
with italics
</w:t>
</w:r>
<w:r>
<w:t>
, a
</w:t>
</w:r>
<w:hyperlink w:rel="rId4" w:history="1">
<w:r>
<w:rPr>
ODF/OOXML Technical White Paper Page 10
<w:rStyle w:val="Hyperlink"/>
</w:rPr>
<w:t>
web link
</w:t>
</w:r>
</w:hyperlink>
<w:r>
<w:t>
and a picture...
</w:t>
</w:r>
</w:p>
<w:p>
<w:r>
<w:pict>
<v:shapetype id="x0000t75" coordsize="21600,21600" o:spt="75"
o:preferrelative="t" path="m@4@5l@4@11@9@11@9@5xe"
filled="f" stroked="f">
<v:stroke joinstyle="miter"/>
<v:formulas>
<v:f eqn="if lineDrawn pixelLineWidth 0"/>
<v:f eqn="sum @0 1 0"/>
<v:f eqn="sum 0 0 @1"/>
<v:f eqn="prod @2 1 2"/>
<v:f eqn="prod @3 21600 pixelWidth"/>
<v:f eqn="prod @3 21600 pixelHeight"/>
<v:f eqn="sum @0 0 1"/>
<v:f eqn="prod @6 1 2"/>
<v:f eqn="prod @7 21600 pixelWidth"/>
<v:f eqn="sum @8 21600 0"/>
<v:f eqn="prod @7 21600 pixelHeight"/>
<v:f eqn="sum @10 21600 0"/>
</v:formulas>
<v:path o:extrusionok="f" gradientshapeok="t" o:connecttype="rect"/>
<o:lock v:ext="edit" aspectratio="t"/>
</v:shapetype>
<v:shape id="x0000i1025" type="#x0000t75"
style="width:431.25pt;height:391.5pt">
<v:imagedata w:rel="rId5" o:title="dalek"/>
</v:shape>
</w:pict>
</w:r>
</w:p>
Rant.
I mitt arbeid må jeg daglig forholde meg til XML som er produsert av andre. En del av min jobb (vagt forklart) er å implementere systemer som tolker og forholder seg til en rekke forskjellige XML-dokumenter. I likhet med mange andre utviklere så har jeg sett litt av hvert når det gjelder strukturering av XML-dokumenter.
En vanlig årsak til vanskapt XML kommer av at man må forholde seg til gamle datasystemer - ofte systemer som har blitt utvidet og sklidd ut i mange år. Det innebærer vanligvis begrensninger som gjør at det ikke lønner seg å starte fra scartch og utforme XML-dokumenter fra bunnen. En vanlig løsning er å ta de eksisterende dataene som produseres, slenge på noen < og > og kalle det XML. Resultatene er dessverre i mange tilfeller gyldig, men vanskapt XML som er vanskelige å forholde seg til.
KISS.
Jeg mistenker at OOXML lider av noe liknende. Strukturen er overkomplisert, tagnavn er forkortet og vanskelige å forholde seg til. Microsoft har ikke begynt på scratch med lettforståelig XML. Det ser ut til at de enten sitter igjen med et tankesett fra sine binære dokumentformater, eller så har de gått inn for å tåkelegge dine dokumenter.
Eksempel: “</text:span>” er i større grad selvforklarende lettere å forholde seg til enn “<w:rPr>”
En (morsom?) øvelse kan være å se på koden som viser bildet i eksempelet. ODF bruker forståelige engelske ord, høyde og bredde er angitt med en velkjent måleenhet. Selvforklarende og enkelt. Tilsvarende for OOXML er ikke forståelig med mindre man har noe å slå opp i foran seg. (Jeg klarer i allefall ikke å gjette hva “path="m@4@5l@4@11@9@11@9@5xe"” skal bety uten å slå det opp.)
Et vanlig argument fra OOXML-leiren er at XML-dokumenter flest leses av maskiner - ikke mennesker. Dette er nok riktig. Men det finnes jo også utviklere som må forholde seg til dette. Bedrifter betaler lønn til utviklere som må forholde seg til et unødvendig rotete format. Utviklere av fri programvare bruker sin fritid på å utvikle applikasjoner som bruker formatet. Små grupper som blinde, svaksynte og dyslektikere trenger ofte nisjeprogrammer som forstår dokumentformatene. Det finnes hackere og nerder som gjerne vil vite hvordan dokumentformatene er satt sammen. Det er ikke en fruktbart strategi å obfuskere dokumentene og heve terskelen for folk som vil se hvordan dokumenter egentlig ser ut.
Argumenter andre veien kjenner jeg egentlig ikke til. (opplys meg gjerne!) For en datamaskin er det (nærmest) likegyldig om den behandler XML som er lettforståelige for mennesker eller obfuskert. Så lenge det er XML vil det gå ut på det samme. Formatene komprimeres, så forkorting av tagger har minimal effekt når det gjelder størrelsen på dokumentet.
0 TrackBacks
Listed below are links to blogs that reference this entry: ODF/OOXML - rent teknisk rant..
TrackBack URL for this entry: http://www.int9.net/mt/mt-tb.cgi/16
Brian Jones hadde en gjennomgang i sin blogg for en stund siden:
http://blogs.msdn.com/brian_jones/archive/2006/05/16/599096.aspx
I kortform er konklusjonen at tagnavnene er forkortet på grunn av hensyn til ytelse, særlig for regneark som kan ha hundretusener av oppføringer.
Særlig har man lagt vekt på å forkorte de tag-ene som det er sannsynlig at gjentas ofte i en fil.
Hei Fredrik.
Interressant lesing - spesiellt mange av kommentarene. Jeg har tenkt en del på denne siden av saken. Magefølelsen sier jo gjerne at jo mindre plass noe tar, desto raskere går det å pløye igjennom for en datamaskin.
Når det gjelder linken til Brian Jones sin posting: Hvorvidt det er riktig konkludere med noe generelt ved å fokusere på et såpass snevert utvalg kan jo diskuteres. Fokuserer du på regneark med millioner av elementer, så gjelder resultatene for disse - ikke for regneark generellt.
Mer interressant er det da å lese http://www.robweir.com/blog/2006/10/why-is-ooxml-slow.html Han tar for seg et større utvalg av faktiske dokumenter, og ikke et mer eller mindre akademisk spesialtilfelle. Han har et bedre utvalg, og etter min mening en mye grundigere undersøkelse. Han konkluderer f.eks. med at et gjennomsnittlig ODF-dokument er 72% så stort som tilsvarende OOXML. Når det gjelder parsetid i en XML-parser så lar ODF seg parse 3.6 ganger raskere.
Men la oss allikevel se på argumentet du kom med i din opprinnelige kommentar.
Tanken er altså at ytelsen trumfer over et selvdokumenterende og intuitivt XML-format. Formatet dokumenteres i standarden, og da er det ikke nødvendig å formatere XML på en måte som mennesker enkelt kan forholde seg til.
Det er i seg selv et helt gyldig argument. Men hvis vi skal godta det, så kan jeg ikke se annet enn at OOXML-leiren har valgt feil verktøy. De bruker en hammer til å slå ned en skrue.
Det de egentlig trenger er et binært format. Microsoft har som du sikkert vet lang tradisjon med binære formater som er vanvittig store. Men dersom de allikevel skal starte fra bunn med et nytt format, ville et binært format vært bedre egnet når det kommer til effektivitet og filstørelse.
Med et binært format vil det være logisk å optimalisere for maskinlesing. Da ville det vært naturlig å dokumentert det fullt ut i én eneste ekstern spesifikasjon som utviklerene har å forholde seg til.