Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Versnelde keuring Open XML vindt doorgang

Nadat we in maart meldden dat Office Open XML in aanmerking kwam voor een versneld standaardisatieproces, heeft de Ecma nu bekendgemaakt dat ooxml uiterlijk binnen vijf maanden beoordeeld moet zijn.

EcmaDe komende vijf maanden zullen de leden van de organisatie hun stem kunnen uitbrengen over de eventuele goedkeuring van de Office Open XML-specificaties als officile iso-standaard,dat het ecma-label al eerder verleend werd. Als alles naar Microsofts wens gaat, dan kan het ooxml-formaat begin augustus iso-gestandaardiseerd zijn en daarmee een volwaardige concurrent van OpenDocument - dat in mei al tot standaard verheven werd - worden. Steeds meer overheden en instanties stellen de eis dat gebruikte bestandsformaten officieel goedgekeurd zijn als Ecma-standaard, maar dat volstaat niet altijd. Zo eist Californi bijvoorbeeld dat er meerdere implementaties van de standaard beschikbaar zijn zodat vrije keuze voor software gewaarborgd blijft. Novell heeft echter al ondersteuning voor ooxml in OpenOffice ingebouwd.

Door Yoeri Lauwers

Eindredacteur

03-04-2007 • 11:20

61 Linkedin Google+

Bron: Ecma

Lees meer

Ooxml wordt ISO-standaard Nieuws van 1 april 2008
Adobe wil iso-stempel voor pdf Nieuws van 29 januari 2007

Reacties (61)

Wijzig sortering
Betekent dit dan ook dat bekende inconsistencies in de Office Open XML standaard er niet uitgehaald gaan worden?

Ik hoop van niet, want dat zal betekenen dat wij als ontwikkelaars over 5+ jaar lekker zullen gaan schelden op de bestaande verantwoordelijken (ECMA cs)

* Little Penguin is van mening dat een standaard naar de toekomst moet werken, niet naar het verleden - zoals nu dus wel met OOXML gebeurt.
En om de reacties over compatibiliteit met huidige binaire office bestanden voor te zijn:
Als we nu al weten wat de fouten zijn kunnen we nu al specificeren hoe een applicatie de conversie moet doen tussen binair en XML...

Dat levert in de toekomst alleen maar voordelen op, omdat we bij het uitlezen van de XML niet na hoeven te denken in hoeverre een bepaald deel van de standaard met bekende[ fouten erin is ontworpen...
Het zegt nog niet zoveel over of ze er wel of niet uitgehaald zullen worden. Daar is het nog te vroeg voor. Het proces van goed- of afkeuren moet nog beginnen.

Nu kunnen eventuele bezwaren tegen goedkeuren op tafel komen en kunnen dus dit soort zaken besproken worden. Als een aantal leden alleen instemmen met goedkeuring als bepaalde MSOOXML-tekortkomingen worden opgelost is er een redelijke kans dat het MS dwingt de standaard te verbeteren.
Onbegrijpelijk dat bijvoorbeeld die datum-bug in het nieuwe XML formaat er weer gewoon in zit, dit had idd in conversieprogramma's naar het oude formaat moeten zitten, en alle overbodige binaire (weet iemand een beter woord voor zooi?) eruit...
Dat het de concurrenten niet gelukt is de versnelde keuring tegen te houden, kan juist ook nadelig uitpakken voor Microsoft.
Immers, niet meer dan een kwart van de stemmende standardiesatie-organen (1 per land) mag tegen zijn, en meer dan 2/3 moet vr zijn.
Aangezien er momenteel nogal wat landen wat bezwaren hebben, en een aantal blanco (dus niet vr stemden) heeft Microsoft bij een versnelde keuring minder tijd om die landen te overtuigen.
Vooral het standaardenorgaan uit Kenia (huiswerk het beste gedaan, lof!) had zr sterke argumenten waarom OpenXML als standaard niet deugde; oa
-OpenXML heeft, anders dan Microsoft beweerd, niets te maken met backwards compability, omdat de macro's uit oude office versies er niet in gespecificeerd zijn,
-OpenXML conflicteert met meerdere ISO standaarden (waaronder de eeuwenoude Gregoriaanse kalender, papierformaten en kleuren)
-OpenXML houdt zich niet aan algemeen aanvaarde XML-afspraken wat betreft leesbaarheid
-Variabele-namen in OpenXML zijn totaal niet consequent wat betreft hoofdlettergebruik
-OpenXML rept over standaarden die niet nader uitgelegd worden, wat niet gebruikelijk is in een standaard,
-OpenXML maakt praktisch geen gebruik van bestaande standaarden, maar definieert eigen standaarden, wat voorkomen moet worden in standaarden,
-OpenXML is 5 x zo snel tot ECMA standaard gemaakt dan in de industrie gebruikelijk, daarom kan de standaard nooit zorgvuldig tot stand gekomen zijn,
-Het is voor standaardiesatie-organen niet te doen 6000 pagina's in vijf maanden (verkort proces) tijd door te nemen, aanmerkingen te maken, verbeteringen op te stellen en door te voeren en deze goed te keuren.
-De EU doet mogelijk nog een anti-trust onderzoek naar de gesloten bestandsformaten van Microsoft.

Verder is de Japanse standaardorganisatie nog bezorgd over de legale status van deelimplementaties, en vraagt de Duitse DIN zich af waarom Microsoft geen aanvullende standaard kan maken op ISO 26300 (ODF) in plaats van met een overlappende standaard te komen (wat volgens ISO niet mag). Singapore zegt (terecht) dat een 6000 pagina's tellende standaard 3e partijen ophoudt / onnodig verward bij het begrijpen van de standaard, dus dat deze onnodig lang is.

De vraag is dus of Microsoft blij moet zijn met de versnelde procedure.
OpenXML maakt praktisch geen gebruik van bestaande standaarden, maar definieert eigen standaarden, wat voorkomen moet worden in standaarden
OOXML herbruikt ongeveer net zo veel ISO standaarden als ODF. ODF gebruikt misschien wat meer W3C standaarden maar dat is niet relvant tijdens ISO standaardisatie omdat W3C standaarden ook regelmatig ISO negeren (bijvoorbeeld SVG).
-OpenXML heeft, anders dan Microsoft beweerd, niets te maken met backwards compability, omdat de macro's uit oude office versies er niet in gespecificeerd zijn
Macro's zijn een scripttaal en dat is wat anders dan een documentformaat. Macro's zijn uitvoerbare code en dat is wat anders dan office document data.
Weliswaar kun je in een document macro's ter aanvulling van de office data gebruiken maar dan hoeven deze nog geen deel te vormen van het formaat. Plaatjes zoals jpeg kun je ook aan een document toevoegen maar documentformaten bevatten ook geen definites van jpeg. Overigens bevat ook ODF geen macrotaal.
-OpenXML is 5 x zo snel tot ECMA standaard gemaakt dan in de industrie gebruikelijk, daarom kan de standaard nooit zorgvuldig tot stand gekomen zijn,
Ecma is een organisatie die bestaande industrietechnologie standaardiseert. OOXML is gebaseerd op de reeds bestaande XML formaten uit MS Office (voor het eerst opgenomen in 2002). Ecma heeft de formaten dus niet zo maar uit het niets gecreerd maar bestaande technologie asl basis gebruikt.
Het is voor standaardiesatie-organen niet te doen 6000 pagina's in vijf maanden tijd door te nemen, aanmerkingen te maken, verbeteringen op te stellen en door te voeren en deze goed te keuren
Dat is ook helemaal niet nodig. Omdat bij fasttracking de standaard vanuit bestaande technologie is voortgekomen en omdat het beheer van de standaard niet zit bij ISO moet ISO niet elke markup elementje afzonderlijk controleren. Het gaat er met name om of de bestaande technologie een door de markt gewenste ISO standaard is en of de Ecma standardisatie en beheer van de standaard vervolgens voldoen aan de kwaliteitseisen van ISO.
OOXML herbruikt ongeveer net zo veel ISO standaarden als ODF. ODF gebruikt misschien wat meer W3C standaarden
Dat is niet waar, ODF gebruikt waar relevant bestaande ISO standaarden, en een van de kritieken op OOXML is dat die dat niet doet op punten waar ODF dat wel doet. Daarnaast gebruikt het ook W3C standaarden, maar je hebt wel een punt als je suggereert dat dat niet relevant is, het gaat hier nl. over de ISO, niet de W3C.
maar dat is niet relvant tijdens ISO standaardisatie omdat W3C standaarden ook regelmatig ISO negeren (bijvoorbeeld SVG).
"Maar mamma hij pakte mijn lollie af! :'(." Dat boeit dus totaal niet. Het gaat er simpelweg om dat het verschillende organisaties zijn. Het lijkt me overigens zelfs dan een plus als standaarden gedeeld worden, bijvoorbeeld als bepaalde standaarden zowel een ISO als een W3C standaard zijn, of zouden kunnen zijn (kwalitatief gezien).

Op dit soort punten moet je in de toekomst kijken en denken (als voorbeeld): hoe maken we ons leven over 50 of 500 jaar niet een complete hel als we proberen om al die 1tjes en 0tjes op die rechthoekige disken te begrijpen om te kijken wat men 50 of 500 jaar terug in de geschiedenis deed?
Alleen programmeurs zullen mogelijk de xmltagging zien en die vinden vast
{1}<w:bgcolor> prettiger dan {2}<WordprocessingML:BackgroundColor>
Hier ga je samen met Microsoft de mist in.
Volgens de XML spec. op basis van SGML (ISO 8879) is het de bedoeling dat mensen makkelijk kunnen lezen wat er bedoeld wordt; de XML moet 'human readable zijn'. In de praktijk betekent dat dat je geen klinkers weglaat.

Voor de standaarden waarvan gezegd wordt "doe het als applicatie X", maar waar niet in de 6000+ pagina's staat hoe dat moet, het volgende:
autoSpaceLikeWord95, footnoteLayoutLikeWW8, mwSmallCaps, shapeLayoutLikeWW8, suppressTopSpacingWP, truncateFontHeightsLikeWP6, uiCompat97To2003, useWord2002TableStyleRules, useWord97LineBreakRules, wpJustification.

Ook al zijn deze elementen optioneel, backwards compability door software die niet door MS is gemaakt wordt niet bereikt door naar het gedrag van deze (binaire) applicaties te verwijzen, maar niet te zeggen hoe dat dan is, zodat reverse engineering nodig is dit te achterhalen. Reverse engineering is echter volgens de EULA's van desbetreffende software verboden, en dus is het effectief onmogelijk bovenstaand gedrag na te bootsen.
Verder verwijst MS op de koop toe naar RTF, MHTML, 'earlier versions of WordProcessingML', en Bitmap, EMF en WMF. Hiervoor geld hetzelfde: op eentje na proprietary formaten van MS; nergens in de nieuwe standaard is een verwijzing te vinden hoe deze opgebouwd zijn.
Samen met het slordige gebruik van hoofdletters en kleine letters door elkaar, vindt ik dat zeker genoeg argumenten om het een baggerstandaard te noemen.

Het is zeer dom van Microsoft (en voor on-achterdochtige mensen onbegrijpbaar) niet voort te bouwen op / aan te vullen bij ISO 26300 dmv. haar lidmaatschap in OASIS.
Dit scheelt ze (en de consument) geldt, moeite, twee incompatibele standaarden over hetzelfde onderwerp, verwarring bij gebruikers, en hierdoor zou MS Office ook compatibel worden met het Chinese UOF (Bestandsformaat met nadruk op bruikbaarheid voor Aziatische talen, wordt onderdeel van ODF).

De enige reden die Microsoft kan hebben om geld over de balk te smijten om een brakke implementatie van een bestaande ISO standaard te willen laten ISO-stempelen en haar eigen klanten te verwarren, en n enkele standaard te onthouden, is dat men concurrentie wil belemmeren, oa. door ervoor te zorgen dat OOXML wl, en ODF niet compatibel is met oude binaire MS-Office / WP documenten.

Zo simpel is het: Bij ODF bekvechten de partijen over hoe de implementatie moet, wat aangeeft dat er concurrentie mogelijk is. Bij OpenXML echter, staat alles vast, en bestaande partijen lopen effectief 6000 pagina's achter op MS-Office2003 bij het implementeren van OOXML (nog afgezien van het feit dat men bepaalde binaire delen van formaten moet 'emuleren'); concurrentievervalsing dus, en een belemmering voor een vrije marktwerking.

Dan heb ik liever (en iedereen die voor een vrije marktwerking is met mij) dat er gebekvecht wordt over hoe het nou moet, wat al aangeeft dat OpenOffice niet de referentie is. Voor OOXML zal MS-Office echter effectief de referentie zijn.

Op dit item kan niet meer gereageerd worden.


Apple iPhone XS Red Dead Redemption 2 LG W7 Google Pixel 3 XL OnePlus 6T (6GB ram) FIFA 19 Samsung Galaxy S10 Google Pixel 3

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank en Intermediair de Persgroep Online Services B.V.
Alle rechten voorbehouden © 1998 - 2018 Hosting door True