a 'mooh' point

clearly an IBM drone

Første kommentarer fra ISO/IEC

Det er pudsigt som man kan have ret. I forgårs (18. november 2007) kom de første rettelser fra ISO/IEC. De har udsendt svarende på i alt 19% af det samlede antal. Deres pressemeddelelse kan ses på ECMAs hjemmeside, hvor den kan studeres nærmere. I korte træk er ISO/IEC-editor Rex Jaeschke begyndt at sende de første rettelser ud. Det sker via et website, hvor de enkelte nationale standardiseringsråd har mulighed for at hente rettelserne til deres forslag. Jeg ved ikke, om fx det franske standardiseringsråd har adgang til rettelserne til de danske, men foreløbigt ser det ud til, at det bliver tilfældet. Indholdet på Hjemmesiden er kun tilgængeligt for de enkelte NB'er (nationale råd), men ifølge Microsofts Brian Jones skyldes det ISO-regler, hvor der specificeres, at kommentarer til forslag og svar på disse er et anliggende imellem ISO og de enkelte lande. I Danmark er Dansk Standard og arbejdet i det underlagt nogle begrænsninger i forhold til fortrolighed, så her skal man nok ikke vente for meget information til at begynde med - men så vidt jeg ved er det diametralt modsat i den engelske pendant til Dansk Standard, så måske skulle man holde øje med de informationer, der kommer ud derfra. Eller - deres regler er ret meget lig de danske, men de har valgt en anden tilgangsvinkel i forhold til arbejdet med OOXML, hvor de bla. har anvendt Wiki'er til at indsamle information, og de har også offentliggjort deres kommentarer til DIS 29500 ligesom vi har gjort i Danmark. Igen er valget af format faldet på en wiki.

Jeg har tidligere refereret til ordsproget "May you live in interesting times" ... og mon ikke de er på vej igen?

Smile

Det begynder at ligne noget

Aktiviteten i OOXML/ODF-sfæren er ved at gå op i et højere gear. Bemærkelsesværdigt nok har de fleste af Microsofts OOXML-resourcer været stort set fraværende på deres blogs siden afstemningen i september, men de er nu begyndt at titte frem igen. Man må håbe, at fraværet var været brugt konstruktivt på feedback til ECMA og Rex omkring kommentarerne til DIS 29500.

Alex Brown (ordstyrer til BRM-konferencen i Geneve i februar 2008) har postet et link til en FAQ, der opridser proceduren for afholdelsen af BRM-konferencen. Alex er i øvrigt medlem af den britiske udgave af Dansk Standard. Som Dansk Standard stemte de vist også Nej (med kommentarer) til DIS 29500. FAQ'en er relativt god læsning, så hvis man er interesseret i processen, er den klart læseværdig. Af specielt interessante områder er punkterne om, hvad der ikke bliver diskuteret på mødet samt, hvordan selve mødet vil blive styret. Der er også nogle kommentarer som hele "P-medlem/O-medlem"-diskussionen, som er blevet misforstået generelt over hle linien. Endelig er det beskrevet bestemmelserne for, om en delegation kan "mixe" antallet af deltagere. Der er et øvre loft på 120 mennesker til møderne, og det giver nogle praktiske udfordringer i forhold til antal delegerede fra hvert land.

Læs den ... du kunne jo blive klogere ...

Smile

Værktøjer, OOXML, System.IO.Packaging

Efter en masse arbejde i de sidste måneder med OOXML i debatter rundt omkring, er turen nu kommet til et par ord om generelt at danne OOXML-filer. Microsoft har frigivet deres understøttelse af OOXML-formatet som en del af Microsoft .Net Framework 3.0 . Det er inkluderet som et nyt namespace i hierarkiet, nemlig System.IO.Packaging. Det er naturlig vis dejligt, at der nu er et helt namespace i .Net til arbejdet med OOXML-filer, men det har desværre den konsekvens, at man skal have installeret .Net 3.0 for at kunne arbejde med det. Har man ikke adgang til .Net 3.0, så skal man have adgang til 3.-parts produkter.

Det første man skal lægge mærke til er navnet på det nye namespace. Det giver nemlig en idé om tilgangsvinklen til anvendelsen af OOXML-filer. Centrum for anvendelsen er nemlig OPC - eller Open Packaging Convention. Så hvis man skulle tro, at man nu skulle til at arbejde med tekstbehandlingsdokumenter eller regneark, så bliver man skuffet. Du skal nemlig til at arbejde med pakkeformatet i OOXML - OPC. 

Nå - men vi skal jo til det

Dannelse af et tekstbehandlingsdokument

Ét af mine kritikpunkter af AODL var jo, at man "kun" kunne arbejde med filer og ikke kunne arbejde med streams. Jeg æælsker streams, så jeg har forsøgt at lave mit eksempel med OOXML som en streambaseret implementering.

[code:c#]

MemoryStream mXml = new MemoryStream();

Package package = Package.Open(<my stream>, FileMode.Create);
Uri uri = new Uri("/jlundstocholm/document.xml", UriKind.Relative);
PackagePart DocPart =
  package.CreatePart(
  uri,
  "application/vnd.openxmlformats-officedocument.wordprocessingml.document.main+xml");

XmlTextWriter writer = new XmlTextWriter(mXml, Encoding.Default);
writer.WriteRaw(@"<?xml version=""1.0"" encoding=""UTF-8"" standalone=""yes""?><w:document xmlns:r=""http://schemas.openxmlformats.org/officeDocument/2006/relationships"" xmlns:w=""http://schemas.openxmlformats.org/wordprocessingml/2006/main"" ><w:body><w:p><w:r><w:t>Hello World!</w:t></w:r></w:p></w:body></w:document>");
writer.Flush();
writer.Close();
byte[] document = mXml.ToArray();
mXml.Close();

using (Stream DocPartStream = DocPart.GetStream(FileMode.Open))
{
  DocPartStream.Write(document, 0, document.Length);
}

package.CreateRelationship(
  uri,
  TargetMode.Internal,
  "http://schemas.openxmlformats.org/officeDocument/2006/relationships/officeDocument",
  "rID1");
package.Close();

fs.Flush();
fs.Close();

[/code]

Kodegennemgang

Det første jeg gør er at åbne et Package-objekt. I mit tilfælde er det på basis af et System.IO.Stream-objekt (my stream), men det kunne også være en simpel filreference. Da jeg skal lave et tekst-dokument tilføjer jeg en adresse på dette (Uri) og danner en PackagePart med denne reference. Hvis jeg ønskede at lave et regneark i stedet, ville det være på nøjagtigt samme måde - men sidste parameter i CreatePart()-metoden er en "ContentType", der skulle ændres til at være til regnearkstypen. Herefter putter jeg via noget stream-gymnastik mit tekstbehandlingsdokument i min PackagePart. XML'en for dette dokument er den XML jeg dannede til eksemplet om den minimale OOXML-fil. Det sidste jeg skal gøre er herefter at definere referencen til den PackagePart, der indeholder mit tekstbehandlingsdokument. Der defineres, at referencen er en intern reference (den kunne også pege ud af pakken) samt hvilken relationstype jeg gerne vil danne. Slutteligt ryddes der op i de oprettede Stream-referencer.

Konklusion 

Hele ovenstående kodeeksempel er jo gennemsyret af selve OPC-formatet - og jeg kan ikke lade være med at tænke: What the fuck? Hvorfor skal det være så svært? Her er AODL-tilgangsvinklen, der er dokument-centrisk - jo noget nemmere at kapere end dette OPC-helvede. Jeg kan godt lide muligheden for at arbejde med streams og ovenstående var sådan semi-sjov at skrive - men helt ærligt? Som udvikler er jeg ikke nødvendigvis interesseret i at kende alle de esoteriske detaljer om OOXML og dens XMl-væsen - jeg vil bare danne et dokument. Det var jo nøjagtigt den måde man tidligere dannede Office-dokumenter på via Office Automation og COM - her skulle man heller ikke vide detaljer om persisteringslogikken ... man skulle blot danne dokumenter.

Jeg har tidligere haft den opfattelse, at én af Microsofts store styrker var/er at udstyre os udviklere med lækre værktøjer, der giver os glæde ved at programmere ... udover selve opgaverne selv, naturligvis. Jeg har også indtil denne artiklel ment, at ODF ville få det svært, da ODF ikke alene skal vinde på desktoppen - det skal også vinde ved os udviklere. Jeg var sikker på, at de værktøjer Microsoft kunne komme med ville slå fx AODL med flere længder. Men det er i hvert fald ikke med denne tilgangsvinkel man vinder os "over", og jeg håber meget, at Microsoft (eller andre) frigiver nogle klasseabstraktionslag til OOXML og OPC, der giver os mulighed for at danne dokumenter som i AODL - og ikke kræver viden om, hvorden det rent faktisk persisteres. Man kan jo passende starte med at kigge i fx klasse-bibliotekerne til dannelse/afsending af emails i .Net (System.Net.Mail.MailMessage). Her er det jo ikke nødvendigt for mig at vide meget om selve mail-formatet for at kunne sende en email. Det klarer klasserne for mig. Måske man kunne blive inspireret her?

Kildekode: OPCCreator.zip (5,39 kb)

Min vurdering (af 5 max mulige smileys)

SmileSmile


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

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!