Tech: February 2008 Archives

Vil gjerne tipse om Software Engineering Radio. Det er en podcast (nesten den eneste så vidt jeg vet) som tar for seg en rekke temaer og intervjuer som er av interesse for oss som er involvert i programutvikling. De har fått til en god balanse når det gjelder stoffet de presenterer. Lytteren klarer å henge med, uten at innholdet blir for overfladisk eller teoretisk.

Utrolig kjekt å høre på til og fra jobb.

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:style­name="P1" text:outline­level="1">
   Example document
</text:h>
<text:p text:style­name="Standard">
   This has some
   <text:span text:style­name="T1">
     bold formatting
   </text:span>
    , also some
   <text:span text:style­name="T2">
     with italics
   </text:span>
   , a
   <text:a xlink:type="simple" xlink:href="http://www.odfalliance.com">
     <text:span text:style­name="Internet20link">
       web link
     </text:span>
   </text:a>
   and a picture...
</text:p>
<text:p text:style­name="Standard">
   <draw:frame draw:style­name="fr1" draw:name="graphics1" text:anchor­type="as­char"
          svg:width="5.9929in" svg:height="5.4362in" draw:z­index="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.