a 'mooh' point

clearly an IBM drone

Password-beskyttelse af en OOXML-fil

I en tråd på v2.dk for snart længe siden blev der højlydt diskuteret indholdet af Stéphane Rodriguez' artikel om OOXML og at OOXML i sig selv er ødelagt pr. design (OOXML is defective by design). Vi diskuterede bla. punkt 10 i artiklen, der taler om tilsyneladende problemer med afhængighed af OLE og password-beskyttelse af et OOXML-dokument som det gøres i MS Office 2007. Omdrejningspunktet i afsnit 10 er det billede, der efterhånden er nået hele verden rundt:

I tråden snakkede vi bla. om, hvordan passwordbeskyttelse laves i OOXML og da vi ikke kunne hitte ud af det, lovede jeg at vende tilbage, når jeg har fundet svaret - og derfor denne artikel.

Passwordbeskyttelse i OOXML og ODF

Passwordbeskyttelse er et område, hvor OOXML i angrebsvinkel adskiller sig fra ODF. I ODF sker passwordbeskyttelse på "part"-niveau, dvs de enkelte dele af ODF-filen krypteres. I ODF-spec (OASIS-udgave) er det beskrevet i afsnit 17.3 Encryption. Der står bla. at hver del-fil i ZIP-filen skal først komprimeres  og herefter krypteres med Blowfish-algoritmen med en nøglelængde på 128 bits (der er nogle andre specifikke, krypteringstekniske detaljer, men de er ikke vigtige her).

Hvis man forsøger at finde ud af, hvordan det gøres i OOXML, så kan man ikke finde noget sted, hvor det står i spec. Det står hverken i Part 4 (Reference) eller i Part 2 (OPC-spec). Det viser sig dog, at der er en grund til miséren. Man har nemlig valgt at lade kryptering af en OOXML-fil være defineret udenfor spec - eller rettere: ikke at definere kryptering. Argumentet jeg fik, da jeg spurgte Microsoft, var, at man dermed ikke låser sig fast på én algoritme og man tillader, at organisationer, der måtte have højere krav til nøglestørrelsen eller egne algoritmer stadig kunne anvende OOXML som dokumentformat

Jeg er ikke sikker på, at jeg er enig i deres designvalg. Det er klart, at der er en vis ræson i at lave et format, som NSA eller DOD kan bruge out-of-the-box (som PHK udtalte på sin blog: Erfaring har vist at når DoD taler, så lytter Microsoft.). Men det giver jo nogle praktiske problemer. Fx kan jeg ikke være sikker på, at jeg som OOXML-konsument kan hitte ud af, hvordan et dokument er krypteret, når jeg modtager det. Det giver nogle uhensigtsmæssigheder i dag. På den anden side er jeg heller ikke helt enig i ODF-valget, da det virker uovervejet, at man har låst sig fast på én krypteringsalgoritme og én nøglestørrelse. Det giver nemlig nogle uhensigtsmæssigheder i fremtiden. Jeg forstår i det hele taget ikke, at man ikke har valgt at bruge fx AES, når man nu skulle vælge algoritme. Det er i øvrigt også pudsigt, at flere kritikpunkter af OOXML fra anti-OOXML-lobbyen netop har gået på, at det skulle være muligt at anvende en hvilken som helst algoritme til kryptering af dele af et OOXML-dokument ... men det var åbenbart ikke noget problem at låse sig fast, da man moslede ODF igennem ISO.

Den famøse OLE-fil

Som nævnt har ovenstående billede været hele verden rundt, og det fortjener naturligvis en behandling. For at finde forklaringen på OLE-filen, så skal man gøre sig det klart, hvilke udfordringer det giver at lave kryptering på pakkeniveau samt ikke at slå sig fast på én metode til kryptering.  Helt overordnet skal der findes en løsning på følgende:

Hvordan er kryptering sket?

Når en OOXML-konsument modtager et OOXML-dokument, der er krypteret, skal det være muligt at finde ud af, hvordan dette er sket. I tilfældet med ODF er dette nemt - man hiver fat i en Blowfish-implementering og gennemløber skridtene i afsnit 17.3 af ODF-spec "bagfra" og så har man det oprindelige dokument. I tilfældet med OOXML er det lidt mere tricky, for man har ikke samme information. Der skal altså findes en løsning til at sikre, at man kan se, hvordan noget er krypteret.

Hvordan skal persistering ske?

Dette er også lidt af en udfordring. Da OOXML er "pakke-agnostisk" er det ikke ligetil at definere en metode, der altid vil virke - for metoden skal jo virke både ved anvendelse af ZIP-filer som overordnet container men også for eventuelle andre måde at anvende OPC. Vær her opmærksom på, at en OPC-pakke reelt er en samling af streams, der er persisterede i en eller anden form. Igen har ODF det nemmere, da valget af én krypteringsalgoritme hjælper dig på vej.

So what can you do?

(eller rettere: hvad gjorde Microsoft?) 

Der skal altså findes en container, der indeholder en eller anden slags beskrivende del (konvolut), hvor man kan skrive, hvilken krypteringsalgoritme man har brugt. Containeren skal også kunne indeholde de krypterede streams, der udgør det oprindelige dokument. I Microsoft Office har man valgt en af Microsoft særdeles velkendt teknologi som container - nemlig en såkaldt "Compound File". Den teknologiske terminologi bag disse filer er også kendt som "Structured storage". Det navn som disse filer er mest kendte under er dog "OLE2 Compound File". "Structured storage" forklares ofte som "a file system within a file". Det er altså en måde at gemme partionerede/opdelte data på - uden at skulle vedligeholde en traditionel filstruktur. På sin vis minder dette meget om ZIP-formatet, der også tillader en slags filstruktur. Det er dog værd at bemærke, at selvom indholdet af en ZIP-fil set via fx WinZip eller WinRAR umiddelbart er anskueliggjort med folder og filer, så er selve indholdet af en ZIP-fil "blot" en række streams, der er persisterede i en samlet container. På samme vis er disse compound files "blot" et antal streams, der er persisterede i en overordnet container.

OLE - WTF?

Inden jeg kaster mig over, hvad man så gør nu, så lad mig lige knytte et par kommentarer til de fordele anvendelse af Compound Files giver. Jeg har til det formål lavet et Excel-ark som i Stéphanes artikel om OOXML og det har jeg beskyttet med et password EncryptedFile.xlsx (12,16 kb). Hvis jeg åbner filen i programmet DocFile Viewer 0.1 ser det således ud



Hver af delene i denne fil repræsenterer en persisteret stream eller en stump metadata. Som jeg nævnte ovenfor, så kræver udeladelse af spec for kryptering en eller anden "konvolut-funktionalitet", hvor man kan finde information om, hvordan den enkelte Compound File skal behandles (dekrypteres), og i denne fil ligger informationen i den del, der hedder "EncryptionInfo" samt i den del, der hedder "StrongEncryptionTransform/Primary. I delen "EncryptionInfo" ligger information om, hvilken komponent, der har lavet krypteringen. I dette tilfælde er det "M i c r o s o f t   E n h a n c e d   R S A   a n d   A E S   C r y p t o g r a p h i c   P r o v i d e r   ( P r o t o t y p e ) ". Det er en del af Cryptographic Application Programming Interface (CryptoAPI) i MS Office. I Excel 2003 kan man vælge imellem flere forskellige måder at kryptere filen på - alle fra dette API. I delen "StringEncryptionTransform/Primary" findes infromationen om, hvilken kryptografisk teknik, der er anvendt. Som det ses herunder er filen krypteret med algoritmen AES og nøglelængde 128. Et hurtigt kig i dokumentationen for CryptoAPI indikerer, at den anvendte Cryptographi Service Provider er PROV_RSA_AES.


Endelig ligger selve indholdet af den krypterede OOXML-fil i delen "EncryptedPackage"

OLE og OLE2 Compound Document Format

Hvis vi er i Windows-verdenen, så er alt stadig rosenrødt - men hvad gør vi nu, hvis vi nu sidder med OpenOffice.org på en Linux-box? Her har man jo ikke adgang til OLE.

Det er her vigtigt at være opmærksom på, at OLE og OLE2 Compound Files er to forskellige ting. OLE2 er en structured storage container - principielt at sammenligne med et ZIP-arkiv (blot uden komprimering). Eksempler på anvendelse af disse containere er MS-Office filer som .DOC, .XLS, .PPT og .VSD (Visio filer). OLE2-filer er i øvrigt ikke begrænsede til Microsoft-programmer. De anvendes generelt af masser af forskellige programmer pga. muligheden for at have "a filesystem within a file". OLE, derimod, er en teknologi, der bla. arbejder med disse filer. OLE er ansvarlig for, at et ODF-dokument i OpenOffice.org (På Windows-platformen), der er linket til et Visio-diagram, kan blive opdateret med ændringer, når diagrammet ændres. OLE er ansvarlig for, at et Word-dokument indeholdende et link til et Excel-ark opdateres, hvis en celle ændres i arket. OLE er ansvarlig for, at man kan lave et Excel-ark med et link til et Corel-dokument, hvor Excel-arket opdateres, hvis Corel-filen opdateres. På en Windows-maskine er OLE i det hele taget ansvarlig for, at det er muligt at anvende andre programmers funktionalitet i ét program, så man ikke skal åbne hvert eneste program for sig.

Men man behøver ikke hverken COM eller OLE for at anvende en OLE2 Compound File.

Det bedste, lavpraktiske, argument for dette er naturligvis, at OpenOffice.org, StarOffice, Google Docs og andre kontorpakker på ikke-Windows-platformen, kan arbejde med Microsoft Office filerne. Hvis det krævede OLE for at kunne det, så ville det ikke være muligt at gøre det på andre platforme end Windows. Vær i øvrigt opmærksom på, at det store arbejde som bla. Sun har gjort med at lave reverse engineering på de binære MS Office-filer var koncentreret omkring selve formaterne (altså hvordan man fx laver fed skrift i Word 2000) og ikke om den stuctured storage container, der indeholder selve Word-dokumentet.

Links af interesse for nogle: KDE.org maillist, What is OLE really about? (MSDN), KOffice maillist, OLE for idiots (MSDN), placering af OLE-storage kildekoden for OOo (i 2004), OOo structured Storage implementering (CVS) 

So what can you do? (Part 2)

Ønsker du at lave det hele fra bunden og implementere din egen structured storage container reader/writer-application, så kan du finde specifikationen for formatet i Microsoft Office 2007 File formats, der kan rekvireres fra Microsofts hjemmeside. Du kan også starte med Microsofts egen forklaring på, hvad disse containere er. Denne information kan du finde på MSDN. Men hvis du allerede har en applikation, der blot skal udbygges til at kunne håndtere krypterede OOXML-dokumenter og ikke gider at lave hele arbejdet selv, så hurra for bla. OSS. Der findes nemlig et væld af forskellige biblioteker (nogle koster penge) derude, der giver mulighed for manipulation af structured storage filer.

En kort og bestemt ikke udtømmende liste over disse er (ikke i nogen bestemt orden efter hverken betydning eller aktivitet)

  • libole2 - udstiller et API til læsning af structured storage filer (licens: GPL)
  • Structured storage library VCL - bibliotek til læsning af Structured storage for Delphi/c++builder udviklere (Licens: n/a, kildekode koster $40)
  • DataConv - generel oversigt over konverteringsværktøjer
  • ripOLE - bibliotek til at trække data ud af OLE2-filer (licens: BSD)
  • Chicago Project - læs Excel-filer (licens: GPL)
  • pole - C++ bibliotek til adgang til OLE2-filer (licens: n/a, men lugter lidt af BSD)
  • libgsf - C-bibliotek (licens: LGPLv2.1)
  • POI - Java API til håndtering af Microsoft Office filer (licens: n/a men er nok en eller anden variant af Apache-licensen)
  • LAOLA - "legendarisk" Perl bibliotek, oprindeligt baseret på reverse engineering af OLE2-filer (licens: GPL)
  • GemBox.CompoundFile - .Net.komponent til at læse, skrive og manipulere OLE2-filer (licens: én licens pr. udvikler, ingen licens for produktionsserver)

Konklusion

Som tidligere nævnt er jeg som udgangspunkt uenig i Microsofts valg af container til den krypterede fil. Set fra Microsofts stol er valget klart nok, men det kunne godt have været gjort nemmere. Det kunne jo være en simpel XML-fil med 3 elementer


Der er ganske sikkert nogle detaljer, som jeg ikke her kan gennemskue - bla. herunder det pakke-agnostiske OPC-format - men jeg er sikker på, at det kunne være gjort på en lidt mere elegant måde. Når det så er sagt, så er det tilbageværende spørgsmål jo: Er der et interoperabilitetsproblem i Microsofts valg af container til håndtering af krypterede OPC-pakker? Nej, det er der ikke. Microsoft har valgt en uelegant måde at implementere password-beskyttelse på, men der er intet, der forhindrer nogen i at arbejde med filerne. Det sker jo allerede i OpenOffice.org, i NeoOffice og alle de andre programmer derude, der kan arbejde med OLE2-filer.

Jeg er helt sikker på, at der er nogen, der vil spinne denne artikel i en retning, der siger: "OOXML indebærer et krav om OLE-tilstedeværelse på den konkrete platform" ... men jeg vil respektfuldt mene, at de tager fejl. Jeg er også helt sikker på, at der er nogen, der vil spinne denne artikel i en retning, der siger: "Jeg sagde det jo, OOXML indebærer dermed via MS Office referencer til OLE" ... men jeg vil respektfuldt påpege, at ovenstående ikke har noget med OOXML at gøre men med MS Office at gøre. Jeg vil også respektfuldt spørge, om det var et problem, hvis OOXML indeholdt referencer til OLE?

Smile

Ønskeseddel til version2.dk

I går havde jeg en hyggelig samtale med redaktøren for Version2(.dk). Jeg havde dér mulighed for at fortælle hende, hvorfor jeg synes, at version2.dk er det bedste online IT-medie herhjemme i øjeblikket, og det svar jeg gav hende var: debatterne.

Man kan jo være uenig med bloggerne/skribenterne på version2.dk i deres holdninger, men det har vist sig, at deres tilgang til debatterne - altså at smide en "krog" ud og se, hvem der bider på" - virker uovertruffent. Dertil kommer, at version2.dk har hvad computerworld.dk mangler i kløgtige debattører hvorimod computerworld.dk har nogle af de ting, som version2.dk mangler i debatforummets brugerflade. Mit budskab var kort og godt:

Lad være med at bruge penge på nye services på version2.dk men brug i stedet pengene på det, som I er gode til og det, som adskiller jer fra konkurrerende sites.

Jeg er - som nogle måske ved - "semi-flittig" bruger af debatforummet på version2.dk, og her er min ønskeliste til jul - skulle man beslutte sig for at kigge på brugerfladen:

1. Tillad HTML i kommentarerne

Det er frustrerende ikke at kunne formattere det indsendte debatindlæg så man kan forstærke ord udtryk med fed skrift, kursiv eller understregning. Det vil også være rart at kunne lave et citat af et indlæg uden selv at skulle indsætte "<" eller lignende foran hver linie.

2. Gør links klikbare

Tja - behøver det mere uddybning?

3. Tillad <name>-navigering imellem kommentarer.

I en debat bliver der også refereret til andre indlæg i samme tråd. Det ville være rart at kunne indsætte et eller andet i sit indlæg, der muliggjorde hurtig navigering til andre indlæg.

4. Gør det muligt at linke til en kommentar

Det ser ud til at burde virke på version2.dk - men det gør det ikke.

5. Implementér undstøttelse af coComment el. lignende

Når man som jeg er meget aktiv på tværs af flere blogs, vil det være rart ét sted at kunne samle sine kommentarer. Nærværende blog understøtter dette, og det er frivilligt at anvende det. Det kunne være en fin feature at implementere.

6. Gør kommentarer søgbare

Det bør være muligt at søge i kommentarer

7. Oversigt over debatindlæg pr. debattør

Som på computerworld.dk vil det være rart at kunne se en liste over alle indlæg fra en konkret debattør. Udvid evt dette med at kunne søge specifikt i en debattørs kommentarer. 

...

Det var sådan set det ... lige nu. Hvad siger I andre? 

Venstrehåndsarbejde på Version2

Version2 er jo en aflægger af Ingeniøren - det ugentlige fagblad for ingeniører. Ingeniøren har igennem mange år opbygget et renomé som en valid faktakilde og defacto-mediet for tekniske, ingeniørmæssige diskussioner og debatter. Ingeniøren har ry for at være et lødigt, teknisk blad og selvom ingeniørkunsten hurtigt bliver politisk i det øjeblik flere end tre interessenter skal dele viden, så har Ingeniøren ikke haft ry for at være farvet politisk den ene eller den anden vej. Ingeniøren har også (tidligere) været kendt og elsket for de dybdeborende artikler om emner, der var interessante for "omverden". Et eksempel på dette var artiklen om stråling fra mobiltelefoner og -master, der hamrede en tyk pæl igennem mange af de hysteriske kommentarer, som debatten i offentligheden på daværende tidspunkt flød over af.

Desværre har IT været underrepræsenteret i Ingeniøren og derfor glædede jeg mig, da jeg så de første udgaver af Version2. Der var for mig klare tegn i sol og måne på, at Version2 kunne udvikle sig til at blive "IT-branchens Ingeniøren" med fokus på teknik og IT og med en velafbalanceret dækning af relevante emner. Specielt glædede jeg mig til at se, hvordan de ville lave Version2s udgave af de dybdeborende artikler fra Ingeniøren - her med fokus på IT.

Jeg blev derfor positivt overrasket, da jeg på forsiden af Version2 for et par uger siden så, at der var en artikel omkring OOXML og ODF. Oplægget (vignetten, eller hvad det end hedder) talte om, at "Alle taler om dem, men få ved, hvad de taler om. Version2 blotlægger indmaden og stiller filer og mappestrukturer til skue". Min tanke var: "Hurra - nu kommer de dybdeborende artikler endeligt".

Artiklen er delt op i to - en ODF-del og en OOXML-del. OOXML-delen (som jeg vil kigge på her) er skrevet af journalist Jakob Møllerhøj. Lad mig slå fast med det samme - der er ikke noget faktuelt forkert i artiklen. Til gengæld er den et fremragende eksempel på, hvordan Version2 er softwarepolitisk farvet og i sine artikler har en åbenbar, tydelig snert af desavouering af OOXML.

Indledende kommentar

Jeg vil gerne understrege, at ovenstående ikke er et personligt angreb på journalisten men derimod en kritik af en artikel, som han har skrevet. I selvsamme udgave af Version2 er der andre artikler af ham, som jeg læste med glæde. Jeg anklager ham derfor ikke for at være en "dårlig journalist" men kritiserer blot, at han har kastet sig ud i at skrive en teknisk artikel,hvor han ikke er godt nok hjemme i stoffet til at gøre artiklen lødig.

MS Office er ikke OOXML

For det første laver journalisten fejlen, at han sammenligner MS Office og OOXML og sætter dem lige. Det er i øvrigt samme hul Finn Gruwier falder i (og naturligvis Stéphane Rodriguez), der har skrevet artiklens modpart om ODF, så man kan sige, at han er i godt selskab. For Finn er det blot ODF og OpenOffice. Jeg ved ikke, hvor misforståelsen kommer fra, men det giver ikke mening at sammenligne hverken ODF og OpenOffice eller OOXML og MS Office. Den af de to programmer genererede XML er naturligvis OOXML hhv ODF, men for begge programmer gælder det, at de ikke danner "minimal" XML men sovser det ind i snavs hist og pist.

OOXML er ikke forstået korrekt

For det andet viser artiklens gennemgang af OOXML, at journalisten ikke helt har forstået de mere basale, esoteriske detaljer og at han desværre bruger denne manglende viden (måske ubevidst?) til uretmæssigt at kritisere OOXML. Lad mig i flæng nævne de tilfælde, hvor kæden hopper af:

  • "Microsoft introducerede OOXML-formatet i den virkelige verden med lanceringen af Microsoft Office 2007-kontorpakken, og gik dermed væk fra det traditionelle binære filformat, som altid har været fremherskende i virksomhedens office-pakker."
    Excel 2003-filformatet var baseret på XML - det som nu er blevet til SpreadsheetML.

  • "En OOXML-fil er en samling af filer i pakkeformatet ZIP. Det vil sige, at eksempelvis OOXML-filtypen .docx, som Word 2007 fil-formatet hedder, kan udpakkes med et almindeligt pakkeprogram som WinZip eller i dette tilfælde Winrar."
    Det er ikke helt forkert men heller ikke helt rigtigt. Som beskrevet i Part 2 af OOXML er OPC-formatet "pakke-agnostisk" og det er kun den fysiske persistering af en OPC-pakke, der anvender ZIP. Dette er i øvrigt præcist som ODF gør det - og som Finn Gruwier Larsen også bemærker det i sin artikel om ODF.

  • "Den udpakkede fil Hello World.docx indeholder en række mapper heriblandt den applikationsspecifikke mappe 'word'."
    Mappen "word" er ikke applikationsspecifik men derimod persisteringsspecifik.

  • ".docProps indeholder egenskaber for den aktuelle applikation. Eksempelvis hvilken Word-skabelon, OOXML-filen skal anvende."
    Som navnet antyder er det ikke applikationsspecifikke ting, der gemmes i mappen docProps men derimod dokumentspecifikke ting. Det drejer sig heller ikke om en Word-specifik skabelon men om en OOXML-specifik skabelon.

Screenshots er misvisende

For det tredje vises der en række screen-shots, der skal underbygge teksten i artiklen. Ét af disse er et billede af den XML-fil, der dannes af MS Office med teksten "Hello World". Men eksemplet er ovenud komplekst og viser ikke reelt, hvad OOXML er. Ikke alene udgøres en del af XML-filen af data, der ikke er relevante for det aktuelle dokument, bla. referencer til skemaer for matematisk indhold, men der er også XML indeholdt, der hidrører fra stavekontrol af dokumentet. I XML-filen er inkluderet et skema med ordene "wordml" - ganske som ODF gør tilsvarende. Dette ord er søreme markeret med blåt, så det giver indtryk af, at det er et problem med denne tekst. Hvis jeg tæller i artiklen, så fremkommer ordet "applikationsspecifik" 4 gange - i øvrigt hver gang forkert - og screenshot er manipuleret, så det fremstår som om at OOXML i sig selv er applikationsspecifik for Word 2007.

Som jeg nævnte ovenfor, så er artiklen ikke en gennemgang af OOXML men derimod en (fejlbehæftet) gennemgang af den XML, som Word 2007 danner. Det er heller ikke et klassisk "Hello World!"-eksempel, da det er unødigt komplekst.

Hjælp til selvhjælp 

For nu at hjælpe journalisten lidt til næste artikel, så har jeg selv dannet mit eget "Hello World!"-OOXML dockument [ Minimal OOXML.docx (1,16 kb) ]. Det er dannet via applikationen "jlundstocholm", hvilket kan ses i mappestrukturen. Jeg har - i modsætning til artiklen - startet med OOXML og ender til sidst med at vise dokumentet i MS Office 2003. For at gøre eksemplet sammenligneligt med ODF-eksemplet er billedet fjernet fra dokumentet.

Indhold af OPC-pakken:

(læg mærke til den persisteringsspecifikke mappe 'jlundstocholm')

Indhold af XML-filen document.xml

(jeg er helt sikker på, at et ODF-dokument kan nedbarberes til tilsvarende størrelse) 

Og filen vist i MS Office 2003

 

For overskuelighedens skyld har jeg også postet indholdet af de to hovedfiler for et ODF-dokument og et OOXML-dokument. Dokumenterne er dannet af hh. OpenOffice 2.2 DA og MS Word 2003 DA. 

OOXML document.xml (1,02 kb)

ODF content.xml (2,57 kb)

Comments from the JTC1-ballot

Chairman of the JTC1 ballot resolution meeting in February Alex Brown has noted on his blog, that the comments accompanying the votes on DIS 29500 OOXML has been released on the JTC1 SC34 website. I just opened a couple of the files and they seem to be stripped from country origin but nevertheless contain information about the specific country (hooray for document properties). I noted, btw, that at least two comment documents appear to have been written by "DANSK STANDARD" ... how's that for conspiracy?

Who will be the first to post statements like "OOXML is out - they will never fix the thousands of comments" ... just by counting them?

Ro på drengen

I fredags d. 7. september kom endnu en frisk udgave af den fysiske udgave af version2.dk . I lederen skrev redaktør Vibeke Hjortlund om OOXML-status i ISO og tiden frem fra nu.

Jeg har mildest talt ikke været imponeret over den redaktionelle linie på version2.dk i debatten imod OOXML. Den af Vibeke lagte linie har været ensidig og anti-OOXML-støttende og antallet af artikler på version2.dk, der har været blot tilnærmelsesvis neutrale, kan så vidt jeg kan søge mig frem til, tælles på én eller max to hænder. Flere af de tekniske artikler, der har været i den fysiske udgave af version2.dk omkring OOXML og ODF har været ikke alene amatøragtigt overfladiske - enkelte af dem har også indeholdt direkte forkert information. Jeg tænker her primært på artiklen i forrige udgave af version2 (fysisk udgave) om OOXML- og ODF-formaterne ... men jeg skriver et indlæg om dette senere. At Vibeke også har tilladt én af sine mest fremtrædende debattører gentagne gange at beskylde mig for at være betalt for at ytre mig til fordel for OOXML - i vore dage hedder det vist en "blog-luder" - taler for sig selv.

Puha - det var dejligt at komme af med ...

Nå - men for nu at komme tilbage til hendes leder, så laver hun jo en slags statusopgørelse over sagens forløb. Jeg er glad for, at hun nævner de åbenbare bagvedliggende markedskræfter i kampen - et faktum som de, der siger at det kun handler om teknik, jo totalt misforstår. Hun skriver bla.

Indimellem skal man huske at kaste et blik på bagtæppet for konflikten - hvor de mangeårige konkurrenter Microsoft og IBM stadig gører overherredømme. Det er en krig om markedet, hvor teknologierne bruges som taktiske våben.

Bagefter giver hun en fortjent røffel til Microsoft for deres stunt i Sverige

Hun skriver skriver i starten af sin leder:

Hvad nu? Efter slaget om ISO-stemplet, standardkrigens hidsige debat, kommentarerne fra de nationale organisationer er det nu tid til ro. Arbejdsro, vel at mærke og det i begge lejre. 

Og hér har hun jo fat i noget af det rigtige. Jeg synes personligt, at det var været røvhamrende hårdt at være en del af debatten. Jeg har - skal det naturligvis siges - nok også været iblandt de mest aktive på pro-OOXML-siden ... og i hvert fald på version2.dk . Men jeg kan også mærke på opponenterne, at de slapper lidt mere af. "Forbrødring" er nok et stort og for stærkt ord at bruge, men tonen er taget én eller to oktaver ned. Ja, jeg er fx begyndt "at tale" med michael rasmussen igen (indlæg 127 - 129 i tråden) og PHK har luftet muligheden for at dele en øl. Det var noget med et væddemål om status efter BRM i februar - hvilket jeg endnu ikke har helt tænkt igennem for muligt udfald. PHK, jeg skal nok hitte på et svar.

Helt konkret sker der jo ikke meget før til februar. Der er møde i JTC1 i december i Kyoto og nævnte BRM-møde i februar 2008. Indtil da skal ECMA arbejde på de ting, som er kommet tilbage til dem som kommentarer. Jeg håber naturligvis, at de tager de gode af disse seriøst. Indtil da er idéen om en øl i øvrigt rigtig god. Jeg har i hvert fald lyst til at møde mange af de, som jeg har debatteret med ... øeh ... irl. Jeg kunne forestille mig noget med, at man mødtes under samme venskabelige forhold, som det har været traditionen ved Firefox release parties. Eneste betingelse jeg har er dog, at det ikke bliver på Ølbaren ... og ja ... naturligvis i det Københavnske. Og så kunne det da være interessant at se, om det kan lade sig gøre at tale om andet end OOXML, ODF og ISO - og i stedet "netweave" lidt, som det hedder på nydansk. Også mere om dette på et senere tidspunkt.

Denmark votes "Conditional approval"

On Saturday September 1st 2007 it was reported by the Danish Standardization committee (Dansk Standard) that it had cast it's vote on DIS 29500. A sub-committee has been working through-out the summer on the result of the public hearing in Denmark and on August 24th, on the last meeting before the official vote, a consensus was reached on the contents of a document to send to ISO alongside with the final vote. No vote was carried out in the meeting and the final decision was left to Dansk Standard to make.

On Saturday the vote was made public. The initial statement was:

Dansk Standard har på vegne af Danmark stemt ”Nej med kommentarer” til forslaget til standarden ISO/IEC DIS 29500 OOXML. Dette indebærer, at Dansk Standard i samarbejdet med standardiseringsudvalget vil arbejde på en godkendelse af Office Open XML som ISO/IEC standard, forudsat at en række punkter adresseres. 

In English this is:

Dansk Standard has on behalf of Denmark voted "No with comments" to the proposed standard ISO/IEC DIS 29500 OOXML. This means, that Dansk Standard in coorporation with the sub-committee wil work on an approval of Office Open XML as ISO/IEC standard , given that a number of points are addressed.

I have tried to translate the rest of the press release here:

In guidance of the international standardization organasition ISO, the proposal ISO/IEC DIS 29500 OOXML has been processed since the beginning of 2007. The proposal adheres to whether Office Open XML should be an ISO/IEC standard. Dansk Standard has as national standardization organisation just cast the vote for Denmark.

Work on the proposal has been done in a committee in guidance of Dansk Standard with participation of 33 companies and organisations. 'IT- og Telestyrelsen' has participated with status of "observer".

ISO/IEC 29500 OOXML has been through a public hearing in Spring of 2007, where everyone has been able to give comments to the suggestion. Dansk Standard recieved 39 comments.

Suggestion from the committee

The committee has has worked constructively and through the late Summer very intense with the comments from the hearing. The result of this work that the committee on August 24th agreed on a consensus on a number of points to improvement of ISO/IEC 29500 OOXML. The committee suggested to Dansk Standard that these points are handed over to ISO. The committee did not cast a guiding vote to Dansk Standard.

Denmark's vote

Dansk Standard has based Denmark's vote on a consensus-evaluation amongst the participating parties as well as on the unanimous consensus agreement.

Denmark will in the process ahead work on an approval of ISO/IEC DIS 29500 OOXML, given that the points that the committee passed on are addressed. With the vote "No with comments" Dansk Standard maintains the best way to take care of the Danish wishes to changes to the standard.

Process ahead

All national standardisation organizations must have cast the vote of their country and submitted any comments September 2nd at the latest. The final decision on whether Office Open XML will become an ISO/IEC-standard is expected to be made on a joint meeting in Geneve on February 25th-29th 2008. At this meeting Dansk Standard will participate as part of a delegation, appointed by the committee. In the delegation additional participants are CIBER Danmark, IBM Danmark, Microsoft Danmark as well as the City of Aarhus, 5th magistrate (Children and youth).

 

Stort nederlag til anti-OOXML fløjen i Danmark

Ifølge en pressemeddelelse fra Dansk Standard har Dansk Standard på Danmarks vegne stemt "No, with comments" til ISO-aftemningen om DIS 29500 (OOXML).

I pressemeddelelsen står der bla.:

Danmark vil i den videre proces arbejde for en godkendelse af ISO/IEC DIS 29500 OOXML, forudsat at de punkter, som udvalget har indstillet, bliver adresseret. Med stemmen ”Nej med kommentarer” sikrer Dansk Standard det bedste udgangspunkt for varetagelse af de danske ønsker til ændringer af standarden.

Når man stemmer "Nej" ved en ISO-afstemning har man samtidig mulighed for at afkrydse en mulighed, hvor man siger, at - givet ens tekniske indvendinger adresseres - vil Nej-stemmen kunne ændres til et "Ja". Den mulighed har Dansk Standard tydeligvist anvendt og reelt er Dansk Standards stemme altså "Betinget Ja". Det lover godt for det fremtidige arbejde med at få OOXML endeligt godkendt.

I Danmark har debatten op til afstemningen været hektisk - ja til tider nærmest hysterisk. Bloggere, journalister og debattører har nærmest faldet over deres egne ben - og hinandens - for at obstruere processen i Dansk Standard ved ikke alene at læse OOXML-spec som fanden læser biblen men også at læse ISO-direktiverne som selv samme. Antallet af debattører i Danmark, der støtter OOXML som ISO-format, har været meget begrænset - ja, udover undertegnede kan antallet vel reelt tælles på én hånd. Jeg vil nødigt give mig selv æren for resultatet af Danmarks stemme, men det er et kæmpe nederlag for anti-OOXML-fløjen, at de med deres store antal debattører, store antal støtter (de siger jo selv, at ODF har en stor installationsbase, stor brugerskare etc) og hysteriske retorik ikke har kunnet få det klare "Nej" igennem, som de agiterer for.

Måske skyldes det, at der et er naturligt mæthedspunkt for, hvor meget man orker at høre på folk, der er ensidige i deres retorik og ikke formår at se to sider af samme sag? 

Ja, man tager sig jo til hovedet

Den anden dag kunne bla. version2.dk fortælle, at Microsoft har tilbudt finansiel støtte til (udvalgte) svenske partnere, hvis de ville stemme "Ja" til OOXML-afstemningen i det svenske SIS-udvalg.

Jeg kan slet ikke forstå, at personen, der sendte disse emails åbenbart stadig er ansat i Microsoft i Sverige. Det er simpelthen så tosse-åndssvagt gjort og personen burde fyres på gråt papir - evt skrevet med fonten "Comic Sans-serif". Jeg er helt sikker på, at for ORACLE, IBM og Microsoft er hele sagen om ISO/OOXML et minefelt uden lige at bevæge sig i, og at formulere en email som denne er et bevis på, at personen ikke har været sit ansvar voksent og har fejlvurderet situationen totalt.

Personligt kan jeg blive så edderspændt rasende over fodfejl som disse. Jeg er af den opfattelse, at IBM, ORACLE, Microsoft og andre spiller "spillet" på samme måde i øjeblikket - og jeg er helt sikker på, der ikke er forskel på de våben de anvender. Man kan måske sige, at (primært) IBM spiller deres kort lidt mere elegant end Microsoft gør i dette tilfælde.

Når jeg bliver så edderspændt sur, så skyldes det, at fejl som disse falder tilbage på sådan nogen som mig. Jeg står fuldt ved min opfattelse af, at OOXML skal ISO-certificeres og jeg baserer denne opfattelse på det tekniske overblik jeg har over formatet. Jeg er også klar til at snakke om forskellige forhold i det omfang nogen skulle ønske det. Jeg har aldrig modtaget noget som helst økonomisk og finansielt af Microsoft eller andre for mit arbejde med OOXML. Men når det alligevel falder tilbage på mig, så skyldes det, at mine argumenter for OOXML nu bliver set i lyset af hændelserne i Sverige, og andre kan (med rette) påstå, at mine holdninger er købt af Microsoft eller andre af dens partnere. Jeg forsøger selv at bygge mine argumenter på et teknisk grundlag - det politiske interesserer mig ikke synderligt - men når Microsoft gør som de gjorde i Sverige, så er det så stort et selvmål i form af "tabt terræn" at klaphatten i Parken til fodboldkampen for et par måneder siden i den grad må se sig slået i forhold til selvdestruktiv adfærd.

Microsoft i Sverige: I burde fandeme skamme jer! 

Trapped in a monopoly's web

Monopolies or monopoly-like situations are seldom a benefit for anyone in the long run - except for the monopolist itself, naturally.  This is regardless of wether the monopoly is controlled by Microsoft, iTunes, Ford, Fox News or Google. Sadly I've been caught in the dominated market of the latter.

Basically, I have/had a need to figure out the amount of a specific filetypes located on the internet. Luckily, Google has a method for doing just this. You simply supply a  "filetype:"-argument to your search, and you can then figure out, that there are roughly 93.700 files of the type "Open Document Text", which are created e.g by the office applications KOffice or OpenOffice. You can also determine that there are roughly 45.100.000 documents of the type "Microsoft Office Word Document", primarily created by the office application Microsoft Office. Now, you can also see, that there are just 1040 files of the type "docx", the filetype of the document type "OOXML".

See, this is kindda weird, since docx-files is the default format for the office application Microsoft Office 2007 - the latest edition of the Microsoft Office-suite ... and by far the most used office application in the world. 1040 files doesn't sound like a whole lot - and it doesn't seem to rightfully represent the document world as it is right now. Some have even spun this as the ... ahem ... naïve ... proof that the world doesn't care about OOXML and that the proposed market penetration of it is a joke.

So ... watcha-ya-gonna-do? Well, I looked at the Google search results and I noticed something. The results of the ODT-search included data like:



Notice that Google's index recognizes the file as a OpenDocument file and correctly displays a portion of the content of it.

But when I looked at the results for the docx-search, it listed data like this:

In case you don't read and understand Danish, Google says that the filetype is unknown ("Ikke genkendt") and - as a consequence - it cannot display the file correctly. Notice also that Google somehow actually managed to display the contents of the embedded files in the docx file container. Well, my conclusion of this is, that OOXML-files are propably not included in Google's index at all and that the few files represent a few "off bits" in Google's spiders/crawlers. Hence the comparison between the result of the odt-search and the docx-search is ... well, moot. Of course ... if you had, say, a business need for it, you could always conclude that there are no docx-files on the internet. My take on this argument is:

Dear Rob, your argument concerning the market penetration of OOXML is the - in the words of Comic Book Guy from the Simpson's - worst argument ever ...

And this brings me back to the title of this post -  coz what can you do, when Google fails? I've looked far and near to find a way to do a similar search, but so far without any luck. Some search-engines allow searh for file types - but limit the choices of valid file types. Most search engines doesn't allow file type search at all. I naturally tried searching using LIVE, but I cannot figure out if it is even possible to have it do the search for me. I have been through most of the engines listed through Search Engine Watch ... but it was a fruitless effort.

My question to you is: where can I go to to find the fact I'm looking for? 

Værktøjer, ODF, AODL

I de sidste par dage har jeg kigget på de tilgængelige værktøjer til generering af ODF-filer - pt. AODL. AODL er en del af ODF Toolkit til generering af ODF-dokumenter og AODL er C#-versionen af dette kit. Kildekoden til dette toolkit kan hentes fra OOs' CVS-repository.

Et ODF-dokument er jo reelt "blot" et ZIP-arkiv indeholdende en række folder og filer og det er et eller andet sted ikke noget, som er relevant for særligt mange. AODL ligger som et objektmæssigt abstraktionslag over dette faktum - og når man anvender biblioteket behøver man ikke at vide dette - altså før det tidspunkt, hvor koden ikke virker. Her er det til gengæld væsentligt at have viden om denne ZIP-fils sttruktur i forbindelse med fejlretning. Ved anvendelse af biblioteket danner man et "regnearks-objekt" (SpreadsheetDocument), hvis man vil lave et regneark, et "teksbehandlingsobjekt" (TextDocument), hvis man vil danne et tekstbehandlingsdokument etc. Man kan tilføje et afsnit (Paragraph) til et tekstbehandlingsdokument og lignende. Abstraktionsmæssigt er implementeringen altså meget tæt på den måde, som man bruger et tekstbehandlingssystem på og det er ganske intuitivt at komme igang med at lave dokumenter.

Et eksempel på dette taget fra AODL-code snippets, der viser dannelse af et tekstbehandlingsdokument:

TextDocument document = new TextDocument();
document.New();
Paragraph paragraph = ParagraphBuilder.CreateStandardTextParagraph(document);
FormatedText formText = new FormatedText(document, "T1", "Some formated text!");
formText.TextStyle.TextProperties.Bold = "bold";
paragraph.TextContent.Add(formText);
document.Content.Add(paragraph);
document.SaveTo("formated.odt");

Ganske tilsvarende er eksempelkoden til generering af et regnearksdokument med en celle med indhold:

SpreadsheetDocument spreadsheetDocument = new SpreadsheetDocument();
spreadsheetDocument.New();
Table table = new Table(spreadsheetDocument, "First", "tablefirst");
Cell cell = table.CreateCell("cell001");
cell.OfficeValueType = "string";
cell.CellStyle.CellProperties.Border = Border.NormalSolid;          
Paragraph paragraph = ParagraphBuilder.CreateSpreadsheetParagraph(spreadsheetDocument);
paragraph.TextContent.Add(new SimpleText(spreadsheetDocument, "Some text"));
cell.Content.Add(paragraph);
table.InsertCellAt(2, 3, cell);
spreadsheetDocument.TableCollection.Add(table);
spreadsheetDocument.SaveTo("F:\tests\simple.ods");

Jeg vil vove den påstand, at selv folk uden dyb programmeringsmæssig baggrund vil kunne give en beskrivelse af, hvad koden gør. Two thumbs up herfra!.

Kodegennemgang:

Selve designet af det begrebsmæssige abstraktionslag for ODF er - sagt igen - rigtigt godt. Jeg kan godt lide at arbejde med objekter med semantisk mening og arkitekturen er sådan relativt gennemført. Der anvendes polymorfi, nedarvning og objekterne er definerede via interfaces de rigtige steder. En løs gennemgang af koden indikerer, at de har lavet det rigtigt godt.

Men mest interessant - uderover objektmodellen - er jo hvordan den bruges. På objektet TextDocument findes en SaveTo()-metode med to overloads. SaveTo() er defineret i interfacet IDocument som både TextDocument() og SpreadsheetDocument() implementerer. Den mest simple af disse overloads tager en "filename"-parameter som argument. Naturligt nok gemmes indholdet af dokumentet i den specificerede fil. Den anden metode tager - udover en filename-parameter - et "IExporter"-objekt. Idéen med dette objekt er, at man kan gemme sit ODF-dokument ved at specificere en konkret exporter. Der medfølger en "PDFExporter" med AODL, og man må antage, at den gemmer ODF-dokumentet som en PDF-fil (jeg har ikke prøvet selv). Idéen er faktisk rigtigt god. Det er dermed muligt at implementere en konkret exporter - til HTML, RTF, OOXML eller hvad man måtte ønske - og så medsende den som argument til SaveTo-kaldet. Men der mangler i mine øjne en overload til SaveTo-metoden. Metoderne jeg kunne ønske mig at have i IDocument-interfacet er:

void SaveTo(System.IO.Stream stream);
void SaveTo(System.IO.Stream stream, AODL.Document.Export.IExporter iExporter);

Rationalet er, at det ikke altid er tilfældet, at man har behov for at persistere et dokument i en fysisk fil på disk. Naturligvis man kan hente den dannede fil fra disk og lave en stream af dette, men det er en lidt omvendt metodik. Skal et dokument dannes via en JIT-tankegang og sendes til fx en browser fra en web-applikation, er det et unødigt niveau af kompleksitet først at skulle danne filen på disk. Her kunne det være lækkert at kunne sende dokumentet til fx en MemoryStream og derefter til klienten. I/O-mæssigt ville dette være det mest optimale. At insistere på at danne en fil undervejs afstedkommer nemlig også yderligere problemer. Selve AODL skal nemlig konfigureres til at gemme filer på bestemte steder og i forbindelse med anvendelse af AODL på web er det ganske sandsynligt at det kommer til at give problemer med skriverettigheder til disk. Men hvis jeg lægger mine "bruger-briller" på hylden og i stedet kigger på AODL med udviklingsøjne, så kunne de næsten ikke implementere det på andre måder. Som nævnt ovenfor er et ODF-dokument reelt en fil- og folderstruktur, der er zippet i en fil. Indholdet af denne zip-fil skal jo være et eller andet sted indtil den dannes, og da der mig bekendt ikke findes metoder til at persistere en folderstruktur i hukommelsen, så har de været nødt til at lave den konkrete implementering.

Konklusion

Helt overordnet set er AODL et behageligt framework at arbejde med. Objektmodellen er intuitiv og let tilgængelig og da den er et OSS-projekt er kildekoden til det også fri. Det er helt klart en fordel og jeg drog netop nytte af dette, da jeg skulle finde ud af, hvordan framework'et var skruet sammen. På den negative side tæller at der i mine øjne mangler nogle muligheder for at gemme til andet end en disk. Det er også frustrerende at dokumentationen er sløset sat sammen - fx er kommentaren ved flere metoder og klasser "Summary of <some class>" - hvilket et default-kommentaren i Visual Studio 2003. Det kunne være rart med en mere gennembearbejdet dokumentation. Hvis man dykker helt ned i koden og eksemplerne herover, vil man lægge mærke til, at der efter instantiering af fx TextDocument() kaldes metoden .New(). Det synes jeg ærligt talt er en smule bekymrende, da et generelt designprincip i OOP er, at et objekt som udgangspunkt skal være klar til anvendelse efter en ctor er kaldet. At kræve at en ekstra metode afvikles er blot at introducere fejl. Fejlhåndtering i klassebiblioteket er også reelt ikke-eksisterende, da fejl blot genkastes, og det giver et overordnet indtryk af, at AODL ikke kvalitetsmæssigt er helt i top.

Min vurdering (af max 5 mulige smileys):

SmileSmileSmile