Ecma rondt beantwoording ooxml-commentaar af

De Ecma heeft alle opmerkingen van de ISO-standaardisatiecomités met betrekking tot Microsofts ooxml-standaard beantwoord en in een document gebundeld. Eind februari moet blijken of de gewijzigde specificatie wordt aangenomen.

Bij de stemming of Ooxml versneld het Iso-standaardiseringproces in mocht gaan, droegen nationale standaardisatiecomités 3522 verbeterpunten aan. Al deze punten zijn nu behandeld door de Ecma, de internationale standaardiseringsorganisatie op het gebied van ict, die ooxml bij de Iso-organisatie als standaard aandraagt.

De Iso-leden krijgen nu zes weken de tijd om het 'Report of Proposed Dispositions' door te nemen en te bekijken of ze het eens zijn met de antwoorden en de voorgestelde wijzigingen, en of die voldoende zijn onderbouwd. Bij een bijeenkomst die eind februari wordt gehouden, zal over elk onderdeel gestemd worden, waarna zal blijken of alle aanpassingen naar de zin van de ISO-leden zijn. Bereiken de partijen die aanwezig zijn bij de bijeenkomst overeenstemming over de wijzigingen in de ooxml-specificatie, dan kan deze alsnog het felbegeerde ISO-keurmerk kijgen.

Het 'Report of Proposed Dispositions' beslaat 2300 pagina's maar de kritiek op het formaat is nog steeds groot, ondanks het grote aantal aanpassingen. Een aantal kritiekpunten werd maandag geuit door Nlnet, de stichting die organisaties financieel ondersteunt die zich inzetten voor een 'open' informatiemaatschappij.

Net als Microsoft is Nlnet lid van de Ecma, maar de stichting noemt het alarmerend dat zelfs commissieleden niet kunnen beschikken over de volledige specificaties van oudere formaten als .doc, .xls en .ppt. "Niemand kan een standaard voor archivering maken of erover beslissen, als ze niet over de originele bestandsformaten beschikken", aldus Michiel Leenaars van Nlnet. Volgens de stichting dienen er nog veel technische onvolkomenheden met betrekking tot de compatibiliteit opgelost te worden. Dit is ook een van de punten die de Europese Commissie meeneemt bij de nieuwe onderzoeken naar Microsoft, op basis van een klacht van de European Committee for Interoperable Systems.

Reacties (38)

[Little Penguin]

Hoewel ik vind dat er diverse technische bezwaren zijn aan OOXML, waaronder de genoemde bugs (maar die kunnen opgelost zijn natuurlijk) en de manier waarop de XML samengesteld is, is er nog een ander punt dat mijns inziens veel belangrijker is.

Namelijk:
OOXML moet een open standaard worden die alleen door toedoen van het ISO(/ECMA), in een open process, gewijzigd kan worden. Hierbij moet ook Microsoft zich 100% aan de OOXML standaard houden en moeten er geen proprietaire extensies door MS in de weggeschreven documenten opgenomen worden.

Als aan bovenstaande voorwaarde niet voldaan wordt, dan krijgen we namelijk hetzelfde debacle als bij .Net/CLI/C# - C# is gestandardiseerd via het ECMA, maar ondertussen heeft Microsoft dus wel tig non-standaard uitbreidingen toegevoegd die erg moeilijk door 3rd parties te implementeren zijn...

* Little Penguin blijft een voorstander van ODF, ondanks de fouten die daar in zitten; maar die zullen in een volgende versie verholpen worden - ODF 1.2 dacht ik.

[Niemand_Anders]

ISO Standaarden kunnen niet worden gewijzigd. Immers een wijziging van een bestaande standaard, betekend dat producten welke aan de standaard voldoen, dan ineens niet meer aan de standaard voldoen. Dat is de reden dat er meerdere PDF specificaties bij ISO zijn neergelegd.

ECMA standaard kunnen wel een update krijgen in de vorm van edities.

Wat betreft de specificaties van C#. De CLR in .NET 3.5 voldoet nog steeds aan de ECMA standaard 335. Alle uitbereidingen in C# zijn gewoon netjes gedeponeerd bij de ECMA. Zie ook ecma standaard 334, 4th edition (juni 2006).

Echter de ECMA had bewaar in het standariseren van namespaces. Die standaard is unaniem door de ECMA leden in 1999 afgewezen. Daar kun je Microsoft niet de schuld van geven. Daarom heeft Microsoft de namespace specificatie naar Novell gestuurt zodat het Mono team deze alsnog kan implementeren. Hetzelfde geldt voor Silverlight (moonlight). Ook die specificaties heeft Microsoft gewoon aan Novell overhandigd zodat Silverlight applicaties ook onder de OS X en Linux kunnen werken.

Van betreft het 'open' maken van een standaard. Voordat een specificatie wordt geaccepteert als standaard kunnen leden (in dit geval van de ECMA) suggesties doen. Wordt een suggestie aangenomen, dan moet deze worden verwerkt. Echter het deponeren van een standaard mag alleen gebeuren door de oorspronkelijk auteur/organisatie. Om die reden kan Microsoft ook geen nieuwe PDF specificatie bij ISO neerleggen. Alleen Adobe heeft de mogelijkheid om daarvan nieuwe specificaties te deponeren. Een van de redenen waarom Microsoft het concurrende XPS heeft ontworpen.

Overigens had je in het artikel kunnen lezen dat de ISO leden ruim 3500 punten veranderd/verbeterd willen hebben. Dat noem ik redelijk open. Wist je trouwens dat C# als taal geruisloos in 2003 (update in 2006) als ISO standaard 23270 is geaccepteert? Alleen jammer dat je bij de ISO moet betalen (328 zwitsere franken) om de standaard te kunnen lezen, terwijl ECMA standaard gratis beschikbaar zijn.

Overigens, is hier de OLE specificatie voor ODF beschreven. Dat zou eigenlijk moetten betekenen dat ODF ook als ISO standaard geschapt moet worden, omdat ook ODF niet het binaire Word document heeft beschreven, terwijl het wel onderdeel van een ODF document kan zijn..

[Reactie gewijzigd door Niemand_Anders op 23 juli 2024 19:10]

[Verwijderd]

Die standaard is unaniem door de ECMA leden in 1999 afgewezen. Daar kun je Microsoft niet de schuld van geven. Daarom heeft Microsoft de namespace specificatie naar Novell gestuurt zodat het Mono team deze alsnog kan implementeren. Hetzelfde geldt voor Silverlight (moonlight). Ook die specificaties heeft Microsoft gewoon aan Novell overhandigd zodat Silverlight applicaties ook onder de OS X en Linux kunnen werken.

Als je een open standaard wil hebben moet je ook aanvaarden dat je aanpassingen afgekeurd worden. En niet als nog implementeren.

Novell is geen standaard organisatie. Ik hoop dat ze het niet implementeren, zeker als de eigenaar van een distro die zich zoveel mogelijk aan open standaarden houd.

[Verwijderd]

Hierbij moet ook Microsoft zich 100% aan de OOXML standaard houden en moeten er geen proprietaire extensies door MS in de weggeschreven documenten opgenomen worden.

Dat is een onnodig en ook zinloos verzoek.
Microsoft is natuurlijk helemaal niet verplicht de ISO standaard te gaan gebruiken. Dat zou echter heel dom zijn omdat organisaties en overheden dat juist graag zullen willen. Bovendien zou het kapitalen kosten om nu weer op een ander formaat over te gaan laat staan dat de klanten van Microsoft dat niet zullen willen en dan niet de nieuwe producten zullen kopen.

Dat er propriety extensies zullen komen lijkt me niet gek.
Zowel ODF als OOXML zijn namelijk juist ontworpen met dergelijk functionaliteit in gedachte. Dit hangt ook samen met het feit dat de door de klant gewenste functionaliteiten veranderen en toenemen en een software ontwikkelaar daar op in zou kunnen spelen zonder 3 jaar te wachten voor een aanpassing doorgevoerd wordt in de standaard.

Overigens zullen deze uitbreidingen juist ook veel gebruikt gaan worden in andere applicaties om bijvoorbeeld bedrijfsspecifieke of applicatie specifieke data in op te slaan.

Custom uitbreidingen hebben echter vermoedelijk weinig impact omdat de standaard functionaliteit van een office suite gewoon al aanwezig is in de formaat specirficaties van ODF en OOXML. Custom uitbreidingen zullen dus de meer niche functionliteiten betreffen en misschien juist wel bedoeld zijn voor speciale doelgroepen zoals bijvoorbeeld gehandicapten.

[joho]

Of die custom uitbreidingen veel impact hebben? MSOffice is een product voor de massa, alles wat er inzit kan door iedereen gebruikt worden. Zelfs al zou MSOffice bij het opslaan aangeven dat het bestand met fratsen word opgeslagen, dan nog zullen de meeste mensen gewoon op Ok klikken. Dus worden er alleen maar 'incompatible' documenten gegenereerd. Net zoals het vroeger was. En dat is nou juist wat ze willen. Closed met het stempel Open.

[kidde]

Microsoft is natuurlijk helemaal niet verplicht de ISO standaard te gaan gebruiken.

Wel als ze in de toekomst office-software aan de Nederlandse overheid - en andere overheden - willen blijven leveren. Gaan ze het niet gebruiken omdat ze vinden dat ze er te weinig invloed op hebben, wat een serieuze mogelijkheid is - zoals Brian Jones in zijn blog aangaf - geven ze toe dat al hun OOXML moeite en het bezoedelen van de naam van ISO voor niets is geweest en ze helemaal geen open standaard willen, hetgeen ik (en velen met mij) al veel langer denk. Gezien het feit dat de nieuwste versie van Mircosoft Office geen compabiliteits export-filter voor OOXML heeft, lijkt dit te gaan uitkomen: Microsoft Office blijft schrijven in gesloten formaten.

Zowel ODF als OOXML zijn namelijk juist ontworpen met dergelijk functionaliteit in gedachte.

Voor zover mij bekend is dat een leugen. ODF is ontworpen zonder proprietaire extenties in gedachte, maar om hypothetisch gezien toch compatibel te blijven met OOXML is deze mogelijkheid later toegevoegd.

Custom uitbreidingen hebben echter vermoedelijk weinig impact omdat de standaard

Gezien de monopoliepositie van Microsoft op de consumenten Office-softwaremarkt en het bestaan van defacto-standaarden (het 'standaard gebruiken van formaten die geen standaard zijn') is het tegenovergestelde juist. Als in ODF een custom-uitbreiding zit, zal 80% van de andere gebruikers deze niet kunnen bekijken - aangezien ze andere applicaties gebruiken dan de maker, en heeft de maker van het document een probleem en wordt als schuldige aangewezen. Voegt iemand in MS Office een custom uitbreiding toe aan een OOXML formaat, zal 95% van de gebruikers deze zonder probleem kunnen gebruiken en bewerken. De 5% die deze niet kan bewerken krijgt waarschijnlijk te horen dat ze maar een standaard-compatibele applicatie moeten gebruiken, terwijl zij zich [i]wel[/i[ aan de standaard houden.

Custom-uitbreidingen in OOXML die - al dan niet open - Microsoft - formaten gebruiken die niet in OOXML beschreven staan vallen bovendien niet onder het 'covenant not to sue'. Dat betekent dat iemand die deze uitbreidingen van Microsoft formaten wil implementeren mogelijk strafbaar bevonden wordt voor inbreuk op Microsoft Intellectueel Eigendom / Monopolie, of deze patenten alsnog in licentie moet nemen, dus waarschijnlijk daarvoor moet betalen.

[Reactie gewijzigd door kidde op 23 juli 2024 19:10]

[SirBlade]

Waarom zou je de volledige specificaties van oudere formaten moeten hebben om te gaan archiveren in een nieuw formaat? Zolang de fabrikant van de software waarmee de documenten zijn gemaakt er maar voor zorgt dat er een conversie tool komt is alles toch in orde. Oude documenten in gesloten formaat erin, nieuwe documenten in open formaat eruit. Vervolgens een steekproef nemen of een vrachtwagen uitzendkrachten regelen om oud en nieuw te vergelijken, klaar.

Je hoeft toch ook niet te weten hoe een printer jouw document van bitjes omzet in inkt, zolang het resultaat op het scherm overeenkomt met wat er op papier staat.

[Blokker_1999]

Waarom zou je de volledige specificaties van oudere formaten moeten hebben om te gaan archiveren in een nieuw formaat?

Als je de specificatie doorneemt dan zal je merken dat er verwezen word naar functies in de oude formaten waarover dus geen documentatie bestaat. De specificatie van ooxml is daardoor in feite onvolledig.

[Verwijderd]

Ik denk dat je het artikel nog eens goed moet lezen. Al deze zaken zijn aangepast:

http://www.ecma-internati...IS%2029500%20complete.htm

[kidde]

Zegt ECMA ja, maar buiten ECMA en de huidige nationale standaarden om kan dat momenteel nog niet gecontroleerd worden.

[Bram S]

wacht even....

-MS heeft in het verleden een aantal bestandsformaten geintroduceerd die gesloten zijn (.doc, .xls, ect). Dit moeten ze uiteraard zelf weten.

-MS wil mee in de trend dat overheden en grote bedrijven (evenals vele kleine gebruikers) vragen om open protocollen.

-MS vindt ODF te beperkend, omdat het geen rekening houdt met hun oude gesloten bestandsformaten en introduceert ooxml. Naar mijn idee redelijk begrijpelijk vanuit hun perspectief, ze willen hun nieuwe producten immers alleen maar compatible houden met de oude.

-MS wil ooxml een officeel standaard laten maken. Dit was niet mogelijk met gesloten standaarden omdat.... tja, deze gesloten waren.

nu stel jij dat de Emca een standaard zou mogen goedkeuren waarvan niemand (behalve MS) weet wat deze precies inhoudt?

Het is niet aan de Emca om te controleren of MS zn werk goed heeft gedaan, het is aan het Emca om te controleren of ieder ander het werk van MS over zou kunnen doen. Dat is namelijk een standaard: iedereen kan het nadoen.

Overigens is jou vergelijking het voorbeeld waarom je vaak beter geen vergelijkingen kan gebruiken, het heeft namelijk niet met de situatie te maken, we hebben het hier over standaarden, niet conversietools.

edit:
@coolmos:
waarom is dat zo gek? Naast het dubbele werk wat YopY aangeeft zie ik nog een probleem: de bestanden die je maakt met iets wat geen standaard is. Heb je een bepaald document gemaakt, kan je het niet lezen in nieuwere versies van MSO, ziet het er anders uit of krijg je andere rare incompatabiliteiten. Naar mijn idee wil niemand dit.

[Reactie gewijzigd door Bram S op 23 juli 2024 19:10]

[Verwijderd]

Je hebt er niets van begrepen.

OOXML is gewoon een volkomen open standaard, waarbij iedereen dus wel weet wat het inhoudt, en iedereen dus ook kan implementeren.

OOXML sluit beter aan op de oude gesloten standaarden, waardoor overzetten van Word en Excell bestanden beter in OOXML dan in ODF kan. Als sommige functionaliteit simpelweg niet bestaat in ODF, en dan is het lastig je document om te zetten. Vooral op spreadsheet gebied schijnt ODF erg beperkt te zijn t.o.v. Excell.

Voor de OOXML specificatie is het irrelevant hoe de oude Office bestanden werken. OOXML is een opzichzelf staande standaard. Dat oude properietaire Office bestanden makkelijk in OOXML kunnen worden omgezet, is een groot voordeel, en een belangrijk reden om OOXML te gebruiken, maar is absoluut geen reden dat plotseling die Office bestandsformaten openbaar zouden moeten worden.

[locke960]

Volgens mij ben jij degene die het niet helemaal begrepen heeft.

In de OOXML specificatie staan tags gedefinieerd als: "autoSpaceLikeWord95", “useWord97LineBreakRules”, “useWord2002TableStyleRules", en "lineWrapLikeWord6".

Doel van deze codes is specifieke opmaak eigenschappen te bewaren als oude office documenten geconverteerd worden. Bijv: je leest een word97 documenten in, vormt het om naar OOXML, en om er voor te zorgen dat de regelafbreking hetzelfde gaat als bij Word97, zodat het er precies hetzelfde uit blijft zien als vroeger, zet je de tag “useWord97LineBreakRules” bij.

Op zich een goed idee als je backwards compatible wilt blijven met je oude versies. Er wordt echter niet bijgezegt wat dat dan precies betekent. Daarvoor moet je in de specificaties van die programma's zijn, en die zijn dus niet open.

Gevolg: jij converteerd je Word 97 bestanden met behulp van Office 2007 naar OOXML. Die tag verschijnt in de geconverteerde bestanden. Je stuurt ze naar mij, ik open ze en omdat mijn niet-MS OOXML applicatie niet weet hoe die tag precies werkt ziet het er toch nog anders uit dan bij jou.

Dat is nou net niet de bedoeling van een standaard.

Om volledig en correct OOXML te kunnen implementeren heb ik dus de specificaties van oudere MS formaten nodig. Die specificaties zijn niet open en dus is ook OOXML niet open.

Als gevolg van de kritiek hierop heeft MS toegezegt deze tags de status "deprecated" te geven. Dat wil je zeggen, je zou ze niet meer moeten gebruiken, maar een implementatie moet nog steeds in staat zijn een bestand met dergelijke codes correct weer te geven. Daar worden we dus niet veel wijzer van.

ps: dat OOXML veel beter aansluit op oudere MS formaten is logisch. Het is oorspronkelijk ontworpen als gewoon de opvolger voor de bestaande MS formaten. Achteraf is men pas op het idee gekomen het als "standaard" aan te bieden. Dat verklaart ook vele andere microsoft-centrische zaken in de "standaard" waar nu zoveel mensen over vallen.

ps2: Wat er ook nog veranderd wordt aan de "standaard", het maakt niet uit. Microsoft heeft hun implementatie al op de markt. Die implementatie gebruikt de draft versie van deze standaard. De draft versie wordt dus gewoon de defacto standard, ongeacht het resultaat van dit standaardiserings circus.

[kidde]

Microsoft heeft hun implementatie al op de markt. Die implementatie gebruikt de draft versie van deze standaard.

Nee, er is momenteel helemaal geen implementatie die opslaat in het formaat beschreven in deze standaard. Microsoft Office slaat tegenwoordig op in MOOXM - een superset van OOXML waarvan het niet zeker is dat deze compatibel is aan OOXML. Zelfs de nieuwste Microsoft Office KAN niet eens opslaan in het ECMA-gestandaardiseerde OOXML, laat staan in de nieuwe versie van deze standaard waarvan de genoemde 2300 pagina's aanpassingen voor gelden.

Niemand gebruikt OOXML dus op dit moment, het is - zoals AHBdV hierboven aangeeft - een op zich staande standaard.

[Reactie gewijzigd door kidde op 23 juli 2024 19:10]

[Verwijderd]

Dit geeft Microsoft zelf ook aan: http://office.microsoft.c...3.aspx?pid=CL100796341033

Why is Microsoft offering a new standard, rather than simply supporting the file format for the Open Office product?

The OpenDocument Format (ODF) does not meet the requirements of backward compatibility

Als dit een argument is moeten alle gebruikers van het OOXML formaat deze mogelijkheid hebben. Dus oude doc,xls etc formaten moeten ook open worden.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 19:10]

[DataGhost]

Het probleem is vooral dat het nieuwe, 'open' formaat dingen kan gebruiken uit het oude, gesloten formaat. Zolang die dingen gesloten blijven kan je natuurlijk niet spreken van een open formaat, dat is waar de schoen wringt. Je blijft nog steeds afhankelijk van Microsoft en anderen kunnen die features niet implementeren, wat wel de bedoeling was.

[Niemand_Anders]

En jij kunt in Koffice geen umbrello uml bestand opnemen? Overigens kun je in een ODF document ook binaire Microsoft Word documenten. De manier waarop dergelijk documenten kunnen worden toegevoegd heet Ole32 en wordt al jaren gebruikt.

Om het moment dat er geen viewer voor een document beschikbaar is (bijv. visio) dan toont Office zelf alleen een pictogram ter aanduiding dat op die plaats een embedded document aanwezig is.

Echter je kunt in een word document ook een WP document opnemen. En behalve voor WordPerfect, Novell en Corel kent niemand de officiele specificaties voor een WP document. Moet Microsoft dit document dan ook specificeren bij de ISO?

Laten we een andere al bestaande ISO specificatie pakken, namelijk PDF. In een PDF document kun je een ShockWave object opnemen. De ShockWave specificaties zijn nooit vrij gegeven, en toch is PDF wel goedgekeurd als ISO standaard. Waarom? Omdat embedded content geen onderdeel is van de specificatie zelf.

Dus leg mij uit waarom PDF wel open is, en het packaging formaat van Microsoft niet? Beide beschrijven alleen hun eigen ding.

[Hadron]

Naar ik me meen te herinneren waren veel dingen in ooxml gebaseerd op Microsoft Office-applicaties. Zoiets als bijvoorbeeld 'Vetgdrukte letters worden behandeld zoals ze in Word 2000 behandeld worden'.
Op die manier is de specificatie van ooxml afhankelijk van de specificatie van Word 2000. En zolang die niet open is (wat zeer waarschijnlijk niet verandert), is de specificatie van ooxml mijns inziens ook niet open.

Jouw voorbeeld van embedded documents is anders. Het gaat daarbij om documenten van andere applicaties die in jouw document ingebed worden. De specificatie hoort daarbij aan te geven hoe dit in het document bijgehouden worden, wat de voorwaarden zijn, etc., maar hoeft niet aan te geven hoe de ingebedde documenttypen werken.

[kidde]

Zie hier:

Adobe haalde alle referenties aan Adobe-specifieke producten uit die ISO-standaard (2.4) en verwijderde termen die er alleen stonden voor terugwaardse compabiliteit met oude Adobe-sotfware.

OOXML staat vol met Microsoft-specifieke zaken die niet alleen <i>verwijzen</i> naar terugwaardse compabiliteit, maar die die terugwaardse compabiliteit met oude Microsoft software zelfs als basis van de standaard zelf en als argument voor het indienen van de standaard hebben.

[SirBlade]

Ik neem aan dat als iemand belangrijke documenten heeft hij er ook voor zorgt dat er een hardware en software is waarmee deze documenten gelezen kunnen worden. BV de pc en software waarmee de documenten gemaakt zijn. MS kan dus of een plugin maken voor oude versies van office waarmee OOXML geschreven kan worden of een bulk-conversie-tool die op windows loopt. Andere OS en programma's ondersteunen is niet direct nodig. Zelf al heb je alle MS-software en licenties weggegooid en zou je een windows+office licentie moeten kopen/huren speciaal voor zo'n project, dat zal nu niet de grootste kostenpost zijn.

Waarom zou MS-office al OOXML moeten kunnen schrijven? De specs zijn toch nog niet definitief, dan krijgen we straks een hele bulk documenten die niet aan de officiele standaard voldoen maar er wel op lijken.

[kidde]

Waarom zou MS-office al OOXML moeten kunnen schrijven?

Om te bewijzen dat het uberhaupt mogelijk is? Daaraan wordt momenteel namelijk getwijfeld.

[Verwijderd]

Dat geld op zijn minst ook voor ODF
Er zijn nog steeds geen onafhankelijk volledig interoperabele ODF implementaties.
Dat is bijvoorbeeld ook lastig omdat bijvoorbeeld OpenOffice allerlei custom setting heeft voor de Office settings tags zonder uitleg wat die eigenlijk doen.

[Verwijderd]

Ik neem aan dat als iemand belangrijke documenten heeft hij er ook voor zorgt dat er een hardware en software is waarmee deze documenten gelezen kunnen worden.

Jahoor en dan heb je na 25 jaar 12 PC's staan met allemaal verschillende Office-versies om je archief te kunnen bekijken. Erg efficient.

[Verwijderd]

Ik kan het alleen maar eens zijn met NLnet.

De Microsoft standaard is niet open en bevat oude fouten die niet gecorrigeerd worden, "schrikkeljaar 2000".

[Verwijderd]

De Tjechen die een stukl of 80 commentaren op de specificatie hadden ingediend hebben de reactie van Ecma op de door hen ingediende comments als geanalyseerd hier:
http://xmlguru.cz/2008/01...e-to-czech-ooxml-comments

[Verwijderd]

De reacties op dit artikel spreken weer eens voor zich. De mensen die hier reageren zijn niet geinteresseerd in de standaard, maar meer dat de bedenker Microsoft is. Als ik zo snel door het commentaar van de Tjechen kijk en de OOXML discussies op het internet volg worden zo goed als al het commentaar van landen en bedrijven verwerkt in de OOXML specificatie. Dit betekent dat iedereen kan ophouden met huilen over "regelafstandalsword95", ed.

Ik snap ook het probleem niet met meerdere documentstandaarden; concurrentie is alleen maar goed. Meerdere standaarden kunnen voor aanzienlijke problemen zorgen, bijvoorbeeld als elk land verschillende formaten treinrails zou gebruiken of in het geval van verschillende DVD standaarden. Bij software bestaat dit probleem echter niet, omdat het extreem makkelijk is om twee documentstandaarden te implementeren voor software. De gebruiker zal niks merken van twee standaarden. Je kan met één druk op de knop documenten overzetten van het ene formaat naar het andere; wat is dan het probleem, het is niet alsof je niet verder kan omdat de rails in het andere land een ander formaat hebben.

Microsoft laat zoveel goodwill zien en toch proberen mensen het af te kraken. Jammer dat een neutrale blik niet mogelijk is.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 19:10]

[Little Penguin]

Bij software bestaat dit probleem echter niet, omdat het extreem makkelijk is om twee documentstandaarden te implementeren voor software. De gebruiker zal niks merken van twee standaarden.

We zullen zien in hoeverre het mogelijk is om in zowel OpenOffice.org (en alle afgeleiden), KOffie en MS-Office zowel OpenDocument als ooxml te implementeren - en dan volledig uiteraard.

Over ODF vs ooxml:
Persoonlijk blijf ik het vreemd vinden dat Microsoft, nota bene lid van OASIS, bij het opzetten van de OpenDocument standaard niet meegedacht heeft en toen gelijk de problemen t.o.v. de compatibiliteit opgepakt heeft...

[Verwijderd]

Dat heeft Microsoft wel degelijk... Alleen zijn ze op dusdanig manier genegeerd, dat Microsoft heeft besloten zijn eigen Open standaard te maken.
Een beetje op dezelfde manier dat DVD+RW is ontstaan uit onvrede over hoe de DVD-R(W) commissie functioneerde.

[Verwijderd]

Alleen zijn ze op dusdanig manier genegeerd, dat Microsoft heeft besloten zijn eigen Open standaard te maken.

MS heeft pas op het allerlaatste moment, toen het dus te laat was om nog grote wijzigingen te maken haar input geleverd. MS is dus helemaal niet genegeerd, MS heeft gewoon willens en wetens haar input veel te laat geleverd.

[Verwijderd]

Persoonlijk blijf ik het vreemd vinden dat Microsoft, nota bene lid van OASIS, bij het opzetten van de OpenDocument standaard niet meegedacht heeft en toen gelijk de problemen t.o.v. de compatibiliteit opgepakt heeft

Dat komt voornamelijk omdat in OASIS ODF puur is bedacht als een formaat voor interoperability van OpenOffice en tijdens de ontwikkeling nooit is gerepresenteerd als een nieuwe wereldstandaard.
In OASIS is slechts 1 keer een standaard oproep gedaan om mee te werken aan een nieuw formaat voor OpenOffice interoperabiliteit.
OpenDocument is ook twee jaar lang ontwikkeld door de OpenOffice XML technische commissie en werd ook die twee jaar OpenOffice XML genoemd.

Pas toen het OpenOffice formaat al zo goed goed als voltooid was heeft men de naam naar OpenDocument veranderd (deze naam is uit een EU rapport overgenomen) en het formaat vervolgens voor ISOs standaardisatie aangeboden.

Het opendocument formaat is dus ook gewoon een nieuwe interoperabele versie van het openoffice formaat en er was nooit reden voor MS om daarin te participeren.

Sterker nog, de OpenOffice XML TC die het formaat heeft ontwikkeld in OASIS heeft op hun eerste meeting vastgelegd dat compatibility met MS Office documenten geen doe was voor dit formaat. Effectief was het formaat dus al vanaf de eerste dag ongeschikt voor Microsoft voor wie compatibiliteit een belangrijke zaak was.

[Verwijderd]

Als je 2 standaarden hebt kan dit wel problemen geven. Een STANDAARD is er voor om te zorgen dat er 1 STANDAARD manier is om iets te doen. Niemand belet Microsoft om met met odt te gaan werken maar alweer wil Microsoft zonodig de touwtjes in handen hebben en niet met "andermans uitschot" werken. Daarom zijn er mensen die Microsoft beginnen te afschuwen omdat dit iedere keer hetzelfde is. Het is niet anders...

Als Microsoft echt iets wil doen aan open source moeten ze .doc opengooien en niet gaan mieren met alternatiefe zooi....

[Reactie gewijzigd door Verwijderd op 23 juli 2024 19:10]

[coolmos]

Het meest bizarre is nog dat zelfs de software van Microsoft niet kan opslaan in OOXML formaat, alleen lezen. Er is dus op de hele wereld geen software te vinden die OOXML kan schrijven. En dat moet een standaard worden?

[YopY]

Als het een standaard wordt kan pas echt bezig gegaan worden met het schrijven van programma's die in OOXML kunnen schrijven. Ze kunnen er nu wel mee bezig gaan, maar als het onderliggende formaat nog aangepast gaat worden is het alleen maar dubbel werk.

Aan de andere kant worden er ook wireless routers gemaakt die gebruik maken van een specificatie van een standaard dat nog geen standaard is.

[Verwijderd]

Zolang de fabrikant van de software waarmee de documenten zijn gemaakt er maar voor zorgt dat er een conversie tool komt is alles toch in orde. Oude documenten in gesloten formaat erin, nieuwe documenten in open formaat eruit.

Heeft Microsoft al zo'n tool gemaakt? en werkt die perfect? want als er een foutje in zit dan kun je dus niks aanpassen. Dat is het grote probleem.
Daarbij zullen ze zo'n tool wel weer enorm duur maken zodat het voor kleine bedrijven erg moeilijk wordt om aan te schaffen.

[ShellGhost]

Ga nu alvast zitten huilen om iets wat nu nog totaal niet duidelijk is.

[Verwijderd]

Hier een link naar een beschrijving die nog erg veel haken en ogen aan ooxml ziet: http://www.fanaticattack....not-answer-in-geneva.html
Kort samengevat: microsoft garandeert nergens dat hun software documenten volgens de toekomstige standaard gaat produceren (office 2007 blijkt al "uitbreidingen" te bevatten die niet in de ooxml standaard zitten, dus andere software zal niet goed met deze documenten overweg kunnen), en de belofte van microsoft over patenten is ook te vaag, volgens deze schrijver.
Nou ja, we zullen wel zien wat het gaat worden bij de ISO...