Microsofts OOXML-standaard komt één stem tekort

Microsoft kwam deze week één stem tekort om een snelle ISO-standaardisatie van OOXML veilig te stellen. Binnen het comité dat de Amerikaanse stem bepaalt waren acht voorstanders, terwijl er negen nodig waren om de 'fast track' op te mogen.

Een van de redenen waarom Microsoft zijn Office Open XML-bestandsformaat probeert vast te laten leggen, is dat organisaties - en met name overheden - steeds vaker het gebruik van open standaarden verplichten. Microsoft wil niet dat men daarvoor alleen bij de concurrentie terecht kan, zoals het door OpenOffice ondersteunde OpenDocument. Het initiatief van Microsoft is echter niet bepaald onomstreden: de 6.000 bladzijden aan documentatie zouden onder ideale omstandigheden al moeilijk te implementeren zijn, maar critici wijzen daarnaast ook op allerlei technische en juridische problemen die er bij komen kijken.

Ondanks deze bezwaren heeft de Europese Ecma de Microsoft-definitie eind vorig jaar als standaard aangenomen, maar de internationale ISO is moeilijker te overtuigen. De INCITS, een club van achttien organisaties die samen de Amerikaanse stem op het gebied van computerstandaarden vormen, besloot deze week opnieuw tégen het voorstel voor versnelde acceptatie van OOXML. Vorige maand werd dat idee ook al afgeschoten, maar omdat de deadline voor de internationale stemming van de ISO pas op 2 september is, had men eventueel nog van gedachten kunnen veranderen.

Dit keer waren voor-stemmers onder andere Microsoft zelf, Apple, Intel, Sony en HP. Tegenstemmen kwamen van onder meer IBM, Oracle en Lexmark. Het IEEE liet zijn stem niet gelden omdat zijn leden het onderling niet eens konden worden. Ook de Amerikaanse overheid verkeert nog in tweestrijd: Homeland Security stemde voor, maar Defensie tegen. Het NIST - dat daags voor de stemronde nog zijn voorwaardelijke steun had toegezegd aan OpenXML - stemde uiteindelijk toch tegen; volgens eigen zeggen omdat aan een 'ja'-stem geen voorwaarden verbonden kunnen worden.

De tegenslag betekent niet dat het idee van OpenXML als ISO-standaard van de baan is, maar wel dat Microsoft er waarschijnlijk een hoop extra werk voor zal moeten doen. Geen van de tegenstanders lijkt echt bezwaar te hebben tegen het initiatief zelf, maar men wil wel een betere uitwerking zien voor ze hun steun durven toezeggen. Amerika is overigens niet het enige land dat het voorstel (waarschijnlijk) gaat verwerpen: onder andere Zuid-Afrika en Portugal zijn ook tegen.

Reacties (36)

[TromboneFreakus]

Goed om te zien dat overheden eindelijk gevoelig worden voor het lock-in effect dat het hanteren van een bepaald bestandsformaat kan opleveren. Nu zij hier op letten, zullen alle softwareleveranciers veel kritischer zijn over hun bestandsformaten en daarmee dus ook op de functionaliteit van hun software (want bestandsformaat zal geen reden meer zijn om product X te nemen).

[TheGhostInc]

Ik weet niet of zoiets meeweegt, er zitten immers ook veel bedrijven in die commisie, het is niet alleen maar (semi-) overheid die het bepaald.

Wat overigens een veel gunstiger effect is, is dat alle andere bedrijven nu langer de tijd krijgen om de standaard te implmenteren en eventuele aanpassingen voor te stellen. 6000 pagina's specificaties is niet niks, en het is wel leuk als niet alleen MS op hun product zet dat ze ISO gecertificeerd zijn, maar dat bijvoorbeeld Apple of Corel dat ook kan. De markt voor Office zou dan weer een klein beetje open kunnen gaan.

[Verwijderd]

Terecht dat het is afgewezen.
Er is al vaak genoeg gewezen op het feit dat er belangrijke fouten in de OOXML zitten. Een van de problemen is dat er formules in het document zitten die niet geheel kloppen. Microsoft zecht dat het belangrijk is dat de formules in het document zitten maar als deze niet kloppen is dat erg gevaarlijk. Rekenfouten in computers kunnen mensenlevens kosten. Denk bijvoorbeeld maar eens aan medisch gebruik.
Veel van de problemen in OOXML zijn dat er geen rekening wordt gehouden met bepaalde eenheden. Een ander probleem met OOXML is dat niet alle internationale standaarden worden ondersteund waardoor er in landen zoals China en Japan problemen ontstaan met charactersets in bepaalde omstandigheden (weblinks bijvoorbeeld)

Zo een standaard kan je dan toch ook niet goedkeuren.

[basfromasd]

Ik vind het shockerend te zien door wie de stem van een land bepaald wordt: IBM, Sony, Microsoft, Apple, Intel, Sony, HP, Oracle, Lexmark, ministeries van defensie en Homeland Security. Dus een aantal grote multinationals samen met twee ministeries die een heel specifieke agenda hebben. Ik zou me daar als inwoner van een land niet door vertegenwoordigd voelen. Alleen NIST en IEEE lijken me organisaties die enigszins rekening houden met het algemeen belang.
Heel eng.
WIe vertegenwoordigt Nederland eigenlijk bij de ISO? NEN misschien?
En wie België?

[Verwijderd]

Het is niet zo heel gek dat dergelijke organisaties betrokken bij standaardisering vraagstukken. Tenslotte zijn deze organisatie belangrijke betrokkenen bij het implementeren van creeren van nieuwe technologieen en implementeren van nieuwe standaarden.

Het gaat hier bijvoorbeeld ook om een fastracking ISO standaardisatie. Dat is standaardisatie van formaten die vanuit de industry wordt aangeleverd (in dit geval via Ecma internationaal) en niet een door ISO ontwikkelde standaard.
Zo zijn bijvoorbeeld ook ISO 9660 (indeling CD-ROM) een door de industry naar voren gebrachte standaard.

[martdj]

WIe vertegenwoordigt Nederland eigenlijk bij de ISO? NEN misschien?

o.a. KPN en voor internetstandaarden als ik me niet vergis ook Surfnet

[Reactie gewijzigd door martdj op 23 juli 2024 01:16]

[tuXzero]

Het feit dat dit standaard betwijfelbaar is zegt al dat het een slecht standaard is. Overigens Microsoft kan (heel makkelijk) het Open Document formaat in hun Office pakket implementeren, het is overigens een ISO gecertificeerd standaard. Waarom doen ze het nu op deze manier, In plaats van ODF implementeren? Ik weet het niet! Maar ik weet wel dat ik het risico niet wil lopen, mocht OOXML problemen gaan opleveren. Of het nu een goed of een slecht standaard is.

PS. Ik gebruik OpenOffice.org. En als MS Office OpenSource was dan werd er nu al heel hard aan gewerkt om ODF ook daarin goed te laten werken.

[Pietervs]

Waarom doen ze het nu op deze manier, In plaats van ODF implementeren? Ik weet het niet!
Lijkt me duidelijk: MS wil een eigen standaard er doorheen drukken. Redenen daarvoor zijn status, macht en beheersbaarheid. Allereerst draagt het schrijven van een internationale standaard bij aan de status van een bedrijf. Ten tweede geeft het macht: MS beweert dan wel dat OOXML een "Open" standaard is, maar met 6000 pagina's waarin ook nog eens verwezen wordt naar interne documenten van MS (die dus niet beschikbaar zijn voor iedereen) heeft MS de vrijheid om concurrenten de voet dwars te zetten (zoals ze met Novell hebben geflikt bij het uitbrengen van SP3 voor Windows NT). Dat geldt natuurlijk ook voor de beheersbaarheid: aangezien MS het geschreven heeft, zullen zij niet (of niet snel) toestaan dat anderen verbeteringen er in aanbrengen, ondanks het feit dat het een "open" standaard is...

[Verwijderd]

Ik ben blij dat er wordt tegengestemd, maar dat ze in principe wel wat zien in OOXML. Vanwege de grote hoeveelheid documentatie is deze standaard een stuk preciezer te implementeren dan de ODF-standaard. ODF-documenten zijn nogal moeilijk compatible te krijgen met verschillende programma's.

Ik ben blij dat er nu wordt tegengestemd, omdat er inderdaad juridische en technische problemen zijn. Er wordt voor een deel van de standaard verwezen naar propriëtaire standaarden, waardoor je juridisch in de problemen kan komen. Ook wordt er verwezen naar gesloten standaarden, waardoor het moeilijk is om het te implementeren. Daarnaast mogen er binary blobs in zitten, die niet doorgrondelijk zijn.

Als Microsoft deze dingen oplost, dan zou dit best eens een hele goede standaard kunnen worden die de closed- en open source werelden dichter bij elkaar brengt.

[Verwijderd]

Er wordt voor een deel van de standaard verwezen naar propriëtaire standaarden, waardoor je juridisch in de problemen kan komen. Ook wordt er verwezen naar gesloten standaarden, waardoor het moeilijk is om het te implementeren.

Dat is dus pure onzin. Tegenstanders van OOXML zeggen dat weliswaar maar hebben nog nooit een voorbeeld weten te noemen van wat je niet kan implementeren van deze OOXML specifcatie met de vrij Open Specification Promise van Microsoft.

Ook van bedrijven die de spec daadwerkelijjk implementeren zoals Apple, Corel en Novel is er geen enkele verzoek to verruiming van de licentierechten.

[Parasietje]

Hoe implementeer ik het attribuut 'TitleLayoutLikeWord97' ? Of de 'FixSpacingLikeWP8'? Dit zijn de twee voorbeelden die steeds opnieuw en opnieuw genoemd worden. OOXML is dus wel degelijk erg moeilijk te implementeren, hoe kan ik weten hoe Word97 precies een Heading1 layoutte? Dat staat helaas niet in de standaard, er staat enkel: "Layout the title just like Word97 would". Nou, dat is even duidelijk...

[Laurens-R]

Mensen die op dat niveau blijven steken hebben toch blijkbaar niet bepaald het inzicht, waar dat document van uit gaat.

Als er staat het mogelijk moet zijn om een layout als in Word 97 te maken, dan betekent dat niet dat je dat bij wijze van spreken als een 'tag' of iets dergelijks (ala <Word97Header>) in je XML moet neerzetten ofzo... Dat betekent dat alle elementen etc die gespecificeerd zijn samen een oplossing bieden om iets vergelijkbaars te produceren.

Een heading 1 layout ala Word 97 voldoet gewoon aan een aantal eigenschappen en OOXML stelt je in staat om die eigenschappen aan te geven. Je weet toch de fontsettings en de linespacing etc? (Die kan je gemakkelijk in Word inzien). Dat in combinatie met het feit dat een header in Word ook meestal een soort bookmark voor de indexering van je document vormt, is genoeg informatie om een Header 1 ala Word 97 te implementer in OOXML. Zolang je maar goed weet hoe de OOXML structuur in elkaar zit.

Zolang dat allemaal in de docs beschreven staat is er toch niks aan de hand...

Een opsomming van mogelijkheden zegt niets over de technische implementatie.. het is slechts een indicatie dat het mogelijk moet zijn. Dat een ontwikkelaar het inzicht niet heeft om z'n brein wat verder te gebruiken is niet het probleem van MS.

Apple, Corel en Novel kunnen het ook, zoals hAl hierboven al zei.

[crisp]

Hetgeen jij beschrijft lijkt toch wel erg veel op reverse-engineering en daarmee onderschrijf je alleen maar de kritiek: om OOXML volledig te kunnen implementeren is kennis van (oudere versies van) MS Office noodzakelijk, en de enige die die kennis volledig in huis heeft is Microsoft zelf. Daarmee is per definitie een volledige interoperabele implementatie onmogelijk.

Dat bepaalde vendors dmv reverse-engineering in de buurt komen, of bepaalde (onbelangrijke?) features dan maar niet implementeren levert hetzelfde op als we nu zien in browsers: de meeste sites werken wel in de meeste browsers, maar er zijn toch nog veel verschillen onderling.

Een specificatie dient volledig, op zichzelf staand en normatief te zijn en dient geen verwijzingen te bevatten naar proprietary (closed) implementaties. Een implementatie zelf is niet normatief...

[Verwijderd]

En dan wat.
Je veranderd de spec.
Ecma gaat die tags eruithalen en Micrsoft stopt hun campatibility info in custom tags.
Komen geconverteerde pre-ooxml documenten voortaan langs met
<custom tag "name=Microsoft compatibility item 45359">

Dit zal Ecma misschien ook wel doen als ze door comments van de national bodies toe worden gedwongen. Zijn ze van het gezeur af en uiteindelijk heeft niemand er een bal aan want de informatie zit nog steeds in die geconverteerde bestanden en je kunt het nu helemaal niet meer interpreteren (zoals bij odf met de ongedocumenteerde offcie settings))

En dat terwijl deze tags juist op verzoek van bijvoorbeeld de library of congress zijn opgenomen om duidelijkheid te verschaffen bij conversie van legacy (pre-ooxml) bestandsformaten)

[Verwijderd]

Hoe implementeer ik het attribuut 'TitleLayoutLikeWord97' ? Of de 'FixSpacingLikeWP8'? Dit zijn de twee voorbeelden die steeds opnieuw en opnieuw genoemd worden. OOXML is dus wel degelijk erg moeilijk te implementeren, hoe kan ik weten hoe Word97 precies een Heading1 layoutte? Dat staat helaas niet in de standaard, er staat enkel: "Layout the title just like Word97 would". Nou, dat is even duidelijk...

Zoals je dat wilt implementeren. Er is in de licentie niet iets wat je dat verhindert.

Er staat ook nergens in de specificaties hoe je een title layout nu moet renderen dus waarom moet er dan wel uitgelegd worden hoe deze in word97 eruitzag.

[Free rider]

Dus VS, Portugal en Zuid Afrika stemmen tegen, en dat is een stem teveel? Welke andere twee landen hebben stemrecht?

Overigens vreemd dat het Japanse Sony invloed heeft op de Amerikaanse stem.

[bthv]

Ik denk dat het hier gaat om de individuele landen, en met de eigen procedure om de standaard te kunnen accepteren. Nederland heeft ook -naast de ISO- eigen keurmerken voor binnen het eigen land.

Ik ben zo ff kwijt welke keurmerken dat zijn voor computersoftware, maar ik weet dat het er is...

[FireWood]

Nederland is NEN
Duitsland is DIN
Belgie is BIN
Internationaal is ISO

[Freee!!]

En Nederland volgt vrijwel altijd DIN.
(Waarom denk je dat we DIN A4 papier gebruiken?).

[Treenaks]

Nee, de standaarden-organisaties werken samen, en één standaard heeft dan vaak ook meerdere nummers (bij elke organisatie een).

A4 is overigens ook ISO 216

[g4wx3]

voor belgie is het bin, denk maar aan de bin normen

[Pietervs]

Nee, binnen de Amerikaanse club die de stem van de VS bepaalt hadden ze 1 stem te weinig: Binnen het comité dat de Amerikaanse stem bepaalt waren acht voorstanders, terwijl er negen nodig waren om de 'fast track' op te mogen.

[Free rider]

Er staat toch echt Microsoft kwam deze week één stem tekort om een snelle ISO-standaardisatie van OOXML veilig te stellen. (eerste regel)

Dus met de Amerikaanse stem zou de versnelde ISO standaardisatie een feit zijn. Ofwel er zijn nationale stemmen, en de Amerikaanse stem wordt bepaald door een telling van voor- en tegenstanders.

Edit - laat maar, t.net was iets te voortvarend in het overtikken van de source. De Amerikaanse stem staat nu vast, maar vele landen mogen kiezen en de versnelde standaardisatie wordt pas op 2 september beslist. Deze kan dus nog steeds doorgaan.

[Reactie gewijzigd door Free rider op 23 juli 2024 01:16]

[Verwijderd]

De amerikaase stem staat helemaal nog niet vast. Het is echter niet een zonder meer approval stem.
Blijft echter over
disapproval
disapproval met commentaar (kan omgezet worden als Ecma de commentaren de komende maanden in voldoende mat beantwoord of zelfs in de OOXML spec verwerkt)
abstain
Daar is nog geen beslissing over.

Het is zeker dat Ecma voor de ballot resultie bij ISO nog een heel stel te maken aanpassinge zal vorleggen waarover de tegenstemmers nog kunnen beslissen of hun bezwaren daarmee voldoende zijn beantwoord.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 01:16]

[Verwijderd]

1 stem klinkt als niet zo veel... maar in dit geval is het wel even 11% te weinig.

[Verwijderd]

Ben ik de enige die het vreemd vind dat defensie stemrecht heeft?

Wat heeft defensie dan voor een functie in deze???

Weird!

[kidde]

Wat heeft defensie dan voor een functie in deze???

*Het Amerikaanse Departement van Defensie (DoD) is de grootste staat-contractor. Het heeft een begroting die groter is dan die van alle andere departementen bij elkaar, $439 miljard (Bron: WP. Het is belangrijk dat men de documenten van state-contractors correct kan bekijken.

*Het DoD maakt veel gebruik van alles wat open is: Open Standaarden, Open Source, Free Software etc.(Bron: LXer migrations list, entry 1,3,4 en 7). Dat neemt alleen maar toe (Bron: The DoD SoftwareTech news, Juni 2007 vol.10 no. 2; gratis inschrijving vereist). Het is voor hen dus belangrijk dat OOXML platform-onafhankelijk is. OOXML is dat momenteel nog niet; zie o.a. het printsysteem (Bron: The case against OOXML, Rob Weir et. all., p 6/10, tweede paragraaf: "Fifth, not only the...)

*In OOXML kunnen proprietaire gedeelten zitten die niet uit te lezen zijn zonder software die alleen op het Windows platform draait. Het DoD draait - om veiligheidsredenen - bijna nergens Windows (kan ik me herinneren). Om hieraan tegemoet te komen heeft ODF ook binaraire gedeelten in haar standaard toegelaten. Echter, het is van software-verkopers afhankelijk of deze geïmplementeerd worden voor ODF of niet. Daarom wil het DoD graag dat deze ook opgenomen worden in de OOXML standaard, lijkt me, want opnemen in ODF vereist of een fork van ODF of een binary blob, en dan zouden ODF gebruikers de problemen moeten oplossen van binary blobs in OOXML (Bron: eWeek, Tiffany Maleshefski, Aug '07).

*Oude MS-Office bestanfsformaten als .doc, .xls zijn niet opgenomen en uitgelegd in OOXML. Aan de belangrijkste reden die Microsoft gaf om niet mee te werken aan ODF en met haar eigen standaard - OOXML - te komen, wordt momenteel dus niet voldaan. Het is in het belang van het DoD dat ook oude documenten correct weergegeven kunnen worden zonder dat daarvoor oude versies van MS-Office en Windows nodig zijn.

*OOXML maakt gebruik van propriëtaire cryptografie-algoritmen (Bron: Grokdoc EOOXML objections, 7.8), die vrijwel zeker onveilig zijn omdat ze niet door genoeg derden bekeken zijn. Het is voor het DoD van cruciaal belang dat de cryptografie-algoritmen open en controleerbaar zijn. 192/256 AES encryptie is goedgekeurd tot documenten van de "Top Secret" classificatie, Bron: National policy on the use of AES, Juni 2003) voldoet bijvoorbeeld wel, maar wordt niet in OOXML ondersteund.

*Het DoD doet zaken met de departementen van defensie van Zuid Korea en Japan. Daarvoor is het gewenst dat OOXML ondersteuning heeft voor meerdere-byte karakters, voorkomende in Aziatische talen. Waar McNeally van Sun heeft aangegeven graag te zien dat ODF in de toekomst fuseeert met UOF, de Chinese office-bestandsformaat standaard (Bron: Consortiuminfo.org, Andy Updegrove, April 07), moet OOXML het momenteel nog stellen met een converter (Bron: WP); dus klaarblijkelijk biedt OOXML daar momenteel nog geen afdoende ondersteuning voor.

*Er zijn in OpenXML bepaalde zaken nog niet opgelost voor mensen met een beperking, al is men aardig op weg. Daarom zegt het "Adaptive Technology Resource Centre" van de universiteit Toronto dat OOXML momenteel nog niet als standaard aangenomen zou moeten worden (Bron: Accessibility issues with OpenXML, Stephan A Hockema et.all). Vanzelfsprekend is het de taak van iedere overheid, dus ook de DoD, te zorgen dat ook mensen met beperkingen met OOXML kunnen werken.

ED_2: Afgezien daarvan, hier is wat het DoD er zelf over te zeggen heeft; en wat ik nog niet genoemd heb:
1) Binary information in the standard that would lead to security concerns. ...
... 3) The use of proprietary file formats within the open standard appear to cause potential intellectual property ownership concerns. (Bron: DoD's commentaar op de NEE stem binnen INCITS, 8 aug 07)

ED - Tweakers wil geen lijstjes meer maken?

[Reactie gewijzigd door kidde op 23 juli 2024 01:16]

[flippy]

je denkt toch niet dat defensie alles in ruwe .txt bestanden doet? die hebben ook allemaal office op de computer staan.

[Verwijderd]

Nee, nu gaan ze stemmen over een voorstel om de Amerikaanse stem te veranderen in een NEE met commentaar (een soort voorwaardelijke nee stem).
Echter omdat de Amerikaanse commentaren zaken bevatten waar Ecma niet aan kan voldoen (bijvoorbeeld het toevoegen van de specificaties van alle voorgaande binary formaten van Microsoft) is dat eigenlijk bijna gelijk een volledige tegenstem. Daar zullen dus de voorstanders van OOXML tegenstemmen (tenzij er een duidelijk mandaat is voor de INCITS vertegenwoordiger om tijdens de ballot resolutie bijeenkomst van ISO om bij het oplossen van specifieke problemen toch de stem naar ja om te zetten.

Het zou er dus best eens op uit kunnen komen dat de VS zich onthoudt van stemming.

[PHiXioN]

Goedzo, reduceer de specificaties maar tot 10% van het huidige en dan praten we verder. De 6000 pagina's bestaan slechts om voor vertraging van implementatie door derden te veroorzaken.

[Verwijderd]

Dit keer waren voor-stemmers onder andere Microsoft zelf, Apple, Intel, Sony en HP. Tegenstemmen kwamen van onder meer IBM, Oracle en Lexmark.

Niet bepaald een objectief groepje bedrijven