Het nieuws, ook op Livre, is nog steeds vol van een strijd tussen twee formaten gebaseerd op XML en beide gericht op de markt voor kantoorautomatiseringsssoftware. Het ene formaat, OpenDocument Format (ODF), vloeit voort uit een Office-product van Sun Microsystems en is snel overgenomen door de open source-beweging. Het formaat wordt ondersteund door onder meer IBM en Sun. Het andere formaat, Office OpenXML (OOXML), vloeit voort uit een product van Microsoft, de partij die de kantoorautomatisering al zeker een decennium in een houdgreep heeft.

ODF is een gepubliceerde, open ISO-standaard: ISO/IEC 26300:2006: Open Document Format for Office Applications v.1.0. OOXML is vastgesteld als een ECMA-standaard en is opgenomen in een ISO-standaardisatietraject, maar nog niet als ISO-standaard vastgesteld. Microsoft zet al haar aanzienlijke marketingmacht (met het onmiskenbare FUD (Fear, Uncertainty, Doubt)-instrument) in om OOXML te promoten. ODF heeft veel backers, maar weinig kapitaal voor marketing, omdat het formaat in principe van niemand is. Dankzij de ISO-status wordt het bestandsformaat steeds meer gebruikt.

De argumenten in de strijd
De argumenten voor het wel of niet gebruiken van beide formaten concentreren zich op de aspecten: open standaard, interoperabiliteit en duurzaamheid.

Open standaard
ODF heeft een uitgebreid revisie- en onderzoekstraject doorlopen voordat het tot OASIS-, en later tot ISO-standaard werd, waarin vele opmerkingen, commentaren en kritieken werden verwerkt. Het formaat is volledig gedocumenteerd en maakt gebruik van XML zoals daarvan gebruikgemaakt moet worden. De ODF-standaard is nog niet compleet (spreadsheets, presentaties). Daar wordt op dit moment, met in achtneming van XML-standaarden, hard aan gewerkt.

OOXML is gestandaardiseerd 'as is', zoals het is aangeleverd bij de ECMA en het standaardisatieproces betrof geen openbare reviewfase. Er is ongeveer 6500 pagina's aan beschrijvende specificaties, die in een niet geloofwaardig recordtempo door de ECMA zijn verwerkt. In het voorbereidende ISO-traject zijn nog nooit zoveel commentaren tegen een voorgenomen standaard ingebracht als tegen het OOXML-voorstel. Het meest voor de hand liggende: er is al een ISO-standaard vastgesteld voor documenten in Office-applicaties (ODF). Dit argument is meestal reden om een voorstel niet in behandeling te nemen. Dit keer niet, want blijkbaar durft de ISO ECMA (en Microsoft) niet voor het hoofd te stoten. Voor de rest zou standaardisatie op grond van vele andere argumenten kunnen worden afgewezen.

Tijdens het maken van vertaal-interfaces van ODF naar OOXML blijkt dat de conversie erg moeilijk gaat, omdat OOXML niet (of niet goed) werkt met XSL Transformations (een W3C-aanbeveling voor het converteren van XML-documenten naar andere XML-documenten) en Xpath (een W3C-aanbeveling om delen van XML-documenten te benoemen voor gebruik door XSLT). XSLT vereist hoog gestructureerde XML. OOXML kan hier blijkbaar niet aan voldoen. Een van de redenen hiervoor is (naast de structuur) het gebruik van 'bitmasks'. Bitmasks zorgen ervoor dat XML niet langer voor het menselijke oog leesbaar en begrijpelijk is. Door bitmasks wordt het voor andere partijen zo goed als onmogelijk om OOXML op de juiste wijze te presenteren. OOXML bevat elementen van 'proprietary' code, die met XSLT niet (of niet met voldoende betrouwbaarheid) te vertalen zijn in een ander XML-formaat, zoals ODF. Dit voorbeeld kan nog met vele andere voorbeelden worden aangevuld. 'Open' is dus relatief. Daarnaast: de Microsoft Open Specification Promise staat geen andere ontwikkelaar toe om het formaat te implementeren. Een open standaard mag door iedereen worden geïmplementeerd.

Het meest frappante is dat ook Microsoft Office zélf geen bestanden kan genereren in het OOXML-formaat. Het door ECMA gestandaardiseerde OOXML is een soort conversie- en importformaat, een kreupele subset van het XML-formaat dat Microsoft Office genereert. We zullen dit laatste MO-OXML noemen. Als een overheidsorgaan uit Massachusetts (of waar dan ook) een tender zou doen uitgaan voor applicaties die ECMA OOXML-formaten zouden moeten kunnen lezen en schrijven (wat een logische eis is, want dit vormt de ECMA-standaard!), dan kan Microsoft Office niet in aanmerking komen. Blijkbaar is dat feit over de openheid van het bestandsformaat nog niet overal doorgedrongen.

Interoperabiliteit
Met het vaststellen dat OOXML niet echt open is (ondanks de qua omvang nauwelijks te verwerken 6500 pagina's documentatie), wordt meteen aangegeven dat interoperabiliteit een vraagteken is. Dat het op XML is gebaseerd wil nog niet zeggen dat het binnen iedere kantoorautomatiseringssuite kan worden gebruikt. Omdat het niet voldoet aan algemeen gebruikelijke XML-eisen, wordt het een moeilijk verhaal. Waar OOXML wel erg goed in is (daarvoor is het tenslotte ontwikkeld!) is het transformeren van de bestaande binaire Microsoft-formaten naar een nieuw, opener en beter gedocumenteerd formaat. Dat is op zichzelf een belangrijk feit, dat het makkelijker maakt om documenten te managen. Overigens: OpenOffice.org kan die conversie ook aan. Qua interoperabiliteit is ODF in principe probleemloos. Ongeacht welke Office-suite op ongeacht welk platform: ODF is lees- en schrijfbaar. Al gaat dat bij MS Office met een omweg, via een (niet door Microsoft zelf) geleverde plug-in.

Duurzaamheid
Ik heb me de afgelopen maanden voortdurend afgevraagd wat het argument van duurzaamheid in deze discussie betekende. ODF is als een open en als een ISO-standaard een duurzaam formaat; OOXML zou dat (als ISO-certificatie plaatsvindt) kunnen worden. Op zich is dat in de dagelijkse prakrijk een belangrijk iets, waardoor conversies worden omzeild. Maar 'duurzaam' betekent ook kunnen beschikken over de inhoud van documenten op een later moment in de tijd, en wel zodanig dat die inhoud gelijk is aan het moment waarop het document werd gegenereerd.

En met dat laatste heb ik bij beide formaten problemen. Beide documentformaten blijven muteerbaar. Het is uiteraard mogelijk om allerlei soft- en hardwarevoorzieningen te gebruiken om onmuteerbaarheid te waarborgen, maar die voorzieningen verdwijnen met de onontkoombare vervanging van hard- en software. Daarbij: duurzaamheid is al geregeld in een andere ISO-standaard, namelijk die van PDF/A (ISO/IEC 19005-1. Document management - Electronic document file format for long-term preservation).

Kortom: beide XML-formaten hoeven zich niet bezig te houden met duurzaamheid van content. Iedere zichzelf respecterende document-, content- of records management applicatie dient zijn opslag te waarborgen op basis van PDF/A. Op het moment dat een document is vastgesteld of afgehandeld, kan een conversie naar dat formaat plaatsvinden. Het argument duurzaamheid in de bestandsformatenstrijd is dan ook niet echt valide.

ODF's wurggreep
De grenzen van ODF worden bepaald door de realiteit van door Microsoft Office gepenetreerde bedrijfsprocessen. Ondanks het groeiende acceptatieniveau wereldwijd voor het formaat, heeft ODF het erg moeilijk.

De Amerikaanse staat Massachusetts heeft recent publiekelijk het mandaat voor open formaten aangepast om de ECMA-standaard 376: OOXML daarin een plaats te geven, met dezelfde status als ODF. Dit gebeurde op 2 augustus. De beslissing is gebaseerd op politieke en praktische overwegingen en niet of nauwelijks op een juridische analyse van de kwalificatie van OOXML als een open standaard. In Massachusetts is de adoptie van OOXML niet onomkeerbaar, omdat op basis van commentaren nog een verandering van standpunt kan volgen. Gezien de gepolitiseerde situatie in Massachusetts lijkt een dergelijke verandering niet voor de hand te liggen, ondanks alle mogelijke aangevoerde argumenten.

De overwegingen in Massachusetts zijn wel de wurggreep waarin ODF gehouden wordt. Het 'mislukken' van het invoeren van ODF in Massachusetts resulteert in de erkenning dat het onmogelijk is om ODF te implementeren in bedrijfsprocessen die strikt gebonden zijn aan de implementaties van Microsoft Office. Het is niet voor niets dat vijf staten in de Verenigde Staten, waaronder Californië, verplichtende wetgeving om ODF te implementeren hebben afgeschoten. Ondanks de massale druk van Sun en IBM die probeerden een 'rip out and replace' implementatie van ODF af te dwingen.

Er is zwaar geïnvesteerd in geautomatiseerde bedrijfsprocessen waarin de kantoorautomatisering in veel organisaties zo goed als cruciaal is. Er is in de meeste situaties geen mogelijkheid om een handmatige inspectie uit te voeren op de geconverteerde documenten. Een vlekkeloze integratie van applicaties is nodig, en de bestaande organisatorische documenten zijn zo goed als volledig opgeslagen in Microsoft's binaire formaten. De betrouwbaarheid van documentenconversie dient zeer hoog te zijn. Vanwege compliance-overwegingen eist de wetgeving een 100 % betrouwbaarheid in de migratie van binaire documenten naar XML. Er bestaat geen 'archief'-wet die niet eist dat opgeslagen documenten accuraat worden behouden. Wat nog veel belangrijker is: er bestaat in de meeste bedrijven meer dan 15 jaar ervaring in het bouwen van bedrijfsprocessen met volledig geïntegreerde applicaties en andere client/server integratie, op basis van Microsoft Office. De afhankelijkheid van die applicatie is bijna 100 %. Daardoor is iets ontstaan wat veel organisaties eigenlijk helemaal niet willen: een klassieke 'vendor lock-in', met een waarlijk, formeel nooit uitgesproken monopolie.

Rip out and replace
Er is een dubbele barrière. Elke implementatie van ODF moet de binaire formaten van Microsoft converteren en vervolgens in staat zijn om in de voorheen aan Microsoft Office gebonden bedrijfsprocessen te integreren, zonder corruptie van de gegevens en met een eenvoudige integratie van de procescripts voor de ODF-applicatie. Dat laatste vormt het probleem.

De kosten en de verstoring die een 'rip out and replace' migratie naar ODF op bedrijfsniveau teweegbrengt, zijn hoog. München bijvoorbeeld besteedde meer dan 3000 euro per werkplek aan de migratie, waarbij het grootste deel van de kosten toe te schrijven valt aan de conversie van bestanden en het vervangen van processcripts in applicaties. Eerlijkheidshalve betrof het hier ook een overgang van besturingssystemen, zodat niet alles op het conto van de Office Suite en het gebruikte bestandsformaat kan worden geboekt.

Toch is 'rip out and replace' de enige oplossing die ODF-leveranciers als IBM en Sun aanbieden aan bedrijven en overheden met integratie- en migratie-eisen van hoge betrouwbaarheid. Een hoogst onverstandige aanpak, zoals Calvin Lawrence (één van IBM's (!) specialisten voor Service Oriented Architecture) al schreef: 'Because most companies have a significant investment in their legacy infrastructure, management is typically not open to ripping out and replacing legacy systems, regardless of the level of shortcomings evident in the infrastructure. Rewriting or significantly modifying large portions of a legacy environment is neither practical nor realistically accomplishable in a reasonable time frame'. De verantwoordelijken voor ODF binnen IBM hebben die uitspraak blijkbaar nooit opgevangen.

IBM en Sun gaan er vanuit dat goede ondersteuning voor ODF in Microsoft Office de levenscyclus van dat product verlengt. Dat is niet wat beide bedrijven willen. Beide bedrijven vergeten het feit dat interoperabiliteit van hoge betrouwbaarheid de sleutel is voor de infiltratie van ODF in bedrijfsprocessen, nu nog gebonden aan Microsoft Office. Voor IBM en Sun gaat het niet om ODF, maar gaat het om de Office-applicaties die zij aanbieden en de marktpositie die ze kunnen winnen door het slagen van een 'rip out and replace'-strategie. Het is een 'battle of giants' met als inzet dominantie van de Office-markt.

Oplossingen
Hoe kan de barrière voor ODF worden geslecht ?

De eerste oplossing, een ODF plug-in voor Microsoft Office, is dezelfde manier als waarop Microsoft zelf bestaande documenten en scripts voor bedrijfsprocessen migreert naar de eigen MO-OXML-formaten. Interne ODF plug-ins zijn klonen van de MO-OXML-plug-in, zoals dat is geïnstalleerd door het Microsoft Office 2007 Compatibility Pack in eerdere versies van de Office-software. Dit is op zich een goede mogelijkheid. Maar de grote ODF-applicatie-verkopers (lees: IBM en Sun) weigeren om de enige bestaande interne plug-in, Da Vinci, te ondersteunen. Door die weigering kan de ODF-conversie vanuit Microsoft Office via Da Vinci in de andere ODF-applicaties niet worden gelezen. Overheden maken dus zowel ODF als OOXML tot open standaard: ze hebben geen andere keuze. De plug-in biedt mogelijkheid om op een kosteneffectieve en niet-verstorende manier over te stappen op ODF. De ODF-leveranciers hebben echter de grote fout gemaakt bedrijven en overheden geen keus te laten.

De tweede benadering is wat complexer:
1. Gebruik OOXML om de binaire bestandsformaten uit het verleden te converteren naar XML.
2. Converteer deze bestanden naar PDF/A (de ISO-standaard voor langdurig te bewaren documenten).
3. Gebruik in de dagelijkse praktijk de converters naar ODF, de beste XML-bestandstandaard (want voldoet aan de XML-standaarden) voor de dagelijkse procespraktijk. Gebruik de Office-suite die men wil, dus ook Microsoft Office (vanwege de Da Vinci plug-in).
4. Converteer alle bestanden die zijn vastgesteld of afgehandeld en om diverse redenen voor wat langere tijd (zeg: langer dan 1 jaar) moeten worden bewaard naar PDF/A.
5. Indien gewenst: bepaal het moment van transitie naar ODF-based Office-suites.

Speelbal
Het lijkt erop dat vooral binnen de Europese Unie het geduld met alle grote leveranciers en hun strijd om marktaandeel op is. Op een conferentie begin maart 2007 hebben de lidstaten een aantal eisen aan de industrie gesteld. De uitkomsten kwamen hierop neer:

• Zowel ODF als OOXML zijn niet acceptabel;
• Microsoft en de grote ODF-leveranciers dienen samen te werken aan de ontwikkeling van een enkel geharmoniseerd bestandsformaat, waarbij ODF de basis dient te leveren.

• 'There is a general dissatisfaction with the perspective of having competing standards;
• There should be one format for one purpose;
• No incomplete implementations, no proprietary extensions;
• Products should support all relevant standards and standards used should be supported by multiple products;
• Conformance testing and document validation possibilities are needed in order to facilitate mapping/conversion;
• Handle the legacy/safeguard accessibility'.