Open XML-problemen waren voor Nederland wel oplosbaar

Ik proef hier toch ook iets anders.

Microsoft probeert een standaard te dicteren, dus een standaard op hun "terms and conditions", en dat staat nu juist haaks op het ontwikkelen van een standaard.

"Nu kan het gebeuren dat je een document precies volgens de standaarden maakt en het toch niet in alle Open XML-tekstverwerkers goed wordt ingelezen", weet hij. "Dat hebben we met een aantal bestanden geprobeerd en in geen geval ging het goed."

Aan de andere kant ziet hij sommige zaken wel drie keer terugkomen en dat voert volgens hem te ver. "Er is drie keer een lijst met 68 papiersoorten. Zo komt de naam A4 zes keer voor en beschrijven de makers vier verschillende maten", betoogt Leenaars. "Dit soort zaken maken het nu heel lastig om goed werkende software te maken."

Ik kan de marketing campagne nu al dromen: Je hebt Microsoft nodig om op basis van deze standaard te kunnen werken. De geitenwollen sokken amateurs met hun Open Source kunnen er weer eens niets van.

Ze willen een standaard waarmee ze zelf het beste mee uit de voeten kunnen en zijn helemaal niet uit op consensus. Het enige doel dat ze hebben met de standaardisatie van Open XML is het behoud van met name de markt van overheden, die duidelijk hebben gemaakt producten op basis van een open standaard te willen selecteren.

Hallo Albert,

Dit lijkt me niet juist.

ik weet niet wat je probeert te zeggen of te suggereren maar het is (zonder enige discussie) wel juist. Mocht je daarover vragen hebben, bel het NEN op (015 2 690 188) en vraag ze om je dit uit te leggen. Zij zullen je precies hetzelfde vertellen. Het zegt natuurlijk alleen iets over de Nederlandse stem, maar daar hebben we het over: niet meer en niet minder.

Beste groet,
Michiel Leenaars

Albert,

je haalt hier sowieso wat zaken door elkaar. Er zijn verschillende lijsten met commentaren: het commentaarpunt waar je naar refereert is een punt dat niet op de lijst stond waar consensus over was. Jij weet bovendien niet dat er meerdere technische manieren zijn om die backwards compatibiliteit intact te houden, en gaat er zo lijkt het voetstoots vanuit dat het dan dus niet aangeraakt mag worden - hoe onzalig de technische oplossing die er nu in de standaard ook staat ook moge zijn. Dat is natuurlijk incorrect. Je gaat niet iets dat in strijd is met een bestaande ISO-standaard zelf standaardiseren alleen maar omdat het op zijn houtje-touwtjes werkt.

Toen Microsoft aangaf de consensus over de stem als enige te zullen blokkeren, is overigens de openlijke vraag gesteld of Microsoft aan kon geven welke commentaren ze dan wel zou willen weghalen uit de lijst. Er waren echter geen commentaren die verwijderd hoefden te worden, een teken dat het probleem elders lag. Toen was al duidelijk gemaakt door NEN dat wanneer deze commentaren (niet meer, niet minder) tijdens de Ballot Resolution Meeting verwerkt zouden zijn Nederland 'automatisch' voor de standaard zou stemmen.

Microsoft koos ervoor om te volharden in haar besluit. Vervolgens vonden anderen dat zij dan ook het recht hadden om de originele onversneden commentaren in te leveren, en niet een verzachte versie waarin de nodige compromissen van hun kant zaten. Hard tegen hard. En dat is uiteraard niet zoals je het graag ziet. Het gevolg is dat we nu niets doen en zullen blijven doen: geen constructieve kritiek, geen mogelijkheid om (als de tekortkomingen straks gerepareerd zijn) de voorgestelde standaard alsnog te steunen. Iedereen verloren, zo lijkt het.

Binnen de Nederlandse commissie die het standpunt over de standaard aan de ISO door moet geven, werd volgens ISOC aangestuurd op een 'nee, mits'. Dat zorgt er binnen ISO voor dat als de opmerkingen verwerkt zijn de stem automatisch een stem vóór de standaard is.


Het is een niet juiste voorstelling van 'conditional approve' dat deze automatisch in een 'approve' verandert. De procedure is dat de afvaardiging van de NEN in zo'n geval wordt gevraagd de stem te bevestigen of te veranderen. Daarbij kan dus worden aangegeven, zonder verplichte opgaaf van redenen, dat de oplossing van de comments niet naar tevredenheid van de commissie is gedaan en blijft de 'disapprove' staan.

Jullie zijn het dus gewoon heel erg eens.

Het verschil zit hem in het vertrouwen in het proces en de insteek die je kiest.

Je kunt geen standaard krijgen op bestelling, dat is misschien even wennen. Je bent voor een open standaard nu een keer afhankelijk van de goedkeuring van de commissie aangaande de oplossing van de comments. Een open standaard is iets anders dan een defacto standaard.

De uitdaging is namelijk de interpretatie: een 'conditional approve' moet worden gebruikt als commentaar als een harde voorwaarde geldt voor een 'approve'. Dus een "Ja, mits". Maar als je de standaard wel goed acht, maar toch commentaar wil insturen is een 'approve with comments' de juiste optie. Dat commentaar wordt dan ook verwerkt (zoals Ecma heeft aangegeven, en zoals vele precedenten binnen ISO aantonen - waaronder ODF (DIS 26300))

Ik denk dat we hiermee de discussie perfect helder hebben. Een "Ja, mits" was niet voldoende omdat het een "disapprove" is met de huidige voorliggende tekst. Wat in wezen geheel correct is, want dat is precies de "mits". Ook te vertalen met "nee, tenzij". De 'approve with comments' is een "Ja, en fix dit nog even", waarbij die fix niet noodzakelijk hoeft op de manier die in de comments is gegeven. Als er iemand anders een "beter bij de Microsoft-way passende" suggestie doet die het geformuleerde probleem ook van tafel haalt, mag die ook worden uitgevoerd. Voor Microsoft was de enige juiste keuze dus een "approve", en indien dat niet haalbaar was, een "abstain". Jammer dat het zo politiek gespeeld moest worden.

de oplossing van de comments niet naar tevredenheid van de commissie is gedaan en blijft de 'disapprove' staan

Beste Hans Bos,

Als er een comissie c.q. instelling is die de standaard beoordeelt en erop moet toezien dat ie ook gehandhaafd wordt, dan is het toch niet meer dan logisch dat wanneer de comments nog niet naar tevredenheid van de beoordelaars is geschied, er nog geen goedkeuring kan volgen.

Het potentiële gevaar zit 'm juist in de "ja, mits" constructie, namelijk het gevaar dat je maar moet afwachten hoe snel het mits wordt verwerkt. De tijd dat het mits nog niet is verwerkt en je dus niet weet hoe het verwerkt wordt en uiteindelijk resultaat zal zijn, bestaat er defacto géén standaard op dat betreffende onderdeel.
De andere partijen die ook op de standaard moeten kunnen bouwen, kunnen dat dan in feite niet, en worden daarmee op achterstand gezet.

Ik kan het helaas toch niet anders zien, dan dat er een achterliggende bijbedoeling in de opstelling van MS zit.

En toch denk ik dat webwereld niet het juiste platform is om hier als commissieleden of belanghebbenden de discussie voort te zetten. Afgezien van de vraag of de berichtgeving helemaal correct is. Daar is immers heel vaak wat op af te dingen. Vandaag werd ook al aan de manier van werken rondom een Skype-artikel getwijfeld.

Al met al blijft dit gewoon een politiek spelletje. Microsoft wil de standaard graag als ISO standaard hebben, en andere marktpartijen proberen dat te voorkomen. Deskundigen die beide standaarden proberen op hun merites te veroordelen, moeten oppassen niet geindoctrineerd te worden door enige partij. En de voorzitter moet er dan vervolgens ook nog eens een zinnige conclusie uit laten komen. Ga er maar aan staan.

Als de sfeer dan zodanig is dat men er samen niet uit kan komen... dan vind ik de conclusie dat men er niet uitkomt heel acceptabel. Als een 'no' niet haalbaar is maar de experts vinden een 'yes' niet te verdedigen, dan hou je toch je mond? Ook al heeft dat dan effectief geen stemmingswaarde, de hele discussie eromheen geeft genoeg stof tot nadenken. Ook voor andere landen die een advies moeten uitbrengen.

In de hoop dat dit geen dubbele post wordt:

Ik zit natuurlijk niet in allerlei belangrijke commissies en mijn onbegrip is grenzeloos, maar volgens de ODF specificatie die ik op http://docs.oasis-open.org/office/v1.1/OS/OpenDocument-v1.1-html/OpenDocument-v1.1.html vond, stond toch echt: Appendix C. MIME Types and File Name Extensions (Non Normative) -> application/vnd.oasis.opendocument.text | odt | Text document

Even kijken hoe het er bij staat met mijn .odt's (hey, dat is een bekende extensie!) in openoffice.org 2.2?
file -i Documents/antwoord.op.wouterv.odt

Documents/antwoord.op.wouterv.odt: application/x-zip

Hm, niet helemaal wat ik verwachtte, (een keurige string a la wat OASIS voorschrijft), maar dat het een zip is kan ik nog net begrijpen als ik de ISO standaard doorlees:
http://standards.iso.org/ittf/PubliclyAvailableStandards/c043485_ISO_IEC_26300_2006(E).zip

17.1 Introduction

As XML has no native support for binary objects such as images, [OLE] objects, or other media

types, and because uncompressed XML files can get very large, OpenDocument uses a package

file to store the XML content of a document together with its associated binary data, and to

optionally compress the XML content. This package is a standard Zip file, whose structure is

discussed below.
[...]

Natuurlijk hoor ik het graag als ik het allemaal verkeerd heb begrepen, maar zit ik nu stiekem te werken met een office applicatie op basis van de ODF ISO standaard?

Nee, waarom zouden ze? Ze hebben geen baat er bij om ODF te steunen. Ze zijn het niet verplicht, hebben de grootste markt. Het lijkt me eerder dat men dus duidelijk hier rekening mee zal moeten houden.

Ik vind het trouwens raar dat er in een nieuwe standaard terugwaartse compatibiliteit moet worden ingebouwd.
Ik heb dit al een paar keer voorbij zien komen en ik denk er ook zo over.
In een programma bouw je een opslagroutine in die het vervaardigde bestand op een bepaalde manier opslaat. Voor Word is dat het .doc formaat. In deze opslagroutine zit op dit moment 20 jaar legacyzooi en bugs.

Er is een nieuwe ISO standaard (ODF :-)
Je bouwt een nieuwe opslagroutine die een bestand in dat formaat opslaat. Alle legacyzooi en bugs in een keer opgeruimd.
Je laat de gebruiker de keuze, opslaan in het legacy .doc of opslaan in ODF. Zo heb je ook meteen de mogelijkheid de .doc bestanden om te zetten in het nieuwe ODF formaat.

Er zullen best een heleboel redenen zijn waarom ik dit verkeerd zie. Ik heb ook niet zo heel veel verstand van programmeren:-) Het principe echter lijkt me logisch.