Office Open XML-problemen waren voor Nederland oplosbaar

Verschillende organisaties zijn van mening dat Nederland weldegelijk tot een 'nee, mits' had kunnen besluiten over het worden van een ISO-standaard van ooxml. Nu dit niet is gedaan, heeft Nederland zijn kans om het proces te beïnvloeden verspeeld.

Vorige week donderdag is door de commissie genaamd 'NEN NC 381034' een besluit genomen over het advies dat aan het ISO gegeven wordt inzake de standaardisatie van de ooxml-specificatie. Tijdens de vergadering is geprobeerd om een meerderheid te krijgen voor de stem 'Approval with comments', maar die was niet aanwezig.

Hierna is gepoogd om alle partijen achter de stemoptie 'Disapproval with comments', een nee-stem die automatisch ja wordt als al het commentaar verwerkt is, maar ook daar waren niet alle partijen het over eens. Hierdoor bleef alleen de uiteindelijk geselecteerde optie 'Abstain' over en heeft Nederland zijn kans om invloed uit te oefenen op het proces verspeeld.

Volgens Michiel Leeners, een van de 'NEN NC 381034'-leden, was het mogelijk geweest om de commentaren die door de commissie waren opgesteld te verwerken in het uiteindelijke voorstel voor de standaard. Zo ontbreken er belangrijke stukken informatie, zoals printerdefinities en scripting. Verder zijn sommige delen van de specificatie te algemeen gesteld en is sommige informatie, zoals over papiersoorten, meerdere keren in het document opgenomen.

Toen tijdens de vergadering van afgelopen donderdag bleek dat er geen meerderheid voor een goedkeuringsstem aanwezig was, had de keus voor een conditionele afkeuring dan ook voor de hand gelegen, aldus Leeners. De realiteit was echter anders. Ook Aad Koppenhol van Sun is niet blij met het uiteindelijke resultaat. Hij had gehoopt dat er uiteindelijk voor een 'Disapproval with comments' was gestemd, zodat uiteindelijk alsnog een positief advies gegeven zou worden.

De Nederlandse commissie is echter voor een 'Abstain' gegaan. Onder andere Wouter van Vugt, ook lid van het comité, schrijft op zijn weblog dat de commissieleden er twee soorten commentaar op na hielden. Bij de eerste stemming waren alle commentaren relevant, maar tijdens de tweede stemming bleek dit niet langer het geval te zijn. Een aantal, zoals 'er bestaat al een standaard, namelijk odf', hadden voor de betrokkenen toen minder waarde.

Tijdens de stemming over de onthouding, kwam ook de vraag aan de orde welke commentaren meegestuurd zouden moeten worden. Volgens Van Vugt bleek toen dat er weer werd teruggegrepen op de eerste set commentaren, waardoor er opnieuw geen overeenstemming bereikt kon worden. Het gevolg hiervan was dat er uiteindelijk voor 'Abstain without comments' is gestemd en de ISO dus niet officieel beschikking krijgt over het Nederlandse werk. Verder betekent dit dat Nederland zich buiten het vervolg van het standaardisatieproces van ooxml gezet heeft.

Reacties (56)

[E-jey]

Leuk, iemand van Microsoft. Raul Pesch, waarom heeft Microsoft een nieuwe standaard ontwikkeld en niet ODF uitgebreid? Lijkt me duidelijk dat het veel handiger is om een enkel standaart te hebben.

Exiss, blu-ray/hd-dvd zijn opvolgers van dvd. ODF en OpenXML zijn concurrenten en geen opvolgers van elkaar. Het is echt niet handig om twee standaarden (technische even goed) voor het zelfde doel te hebben. Het is maar goed dat er voor enkele open standaarden op internet is gekozen anders kon je echt niet makkelijk mailen met de VS (ofzo).

[Raul Pesch]

Waarom niet standaardiseren op 1 soort brandstof: alleen nog maar autogas?
Er zijn redenen te bedenken waarom sommige mensen liever op benzine of diesel rijden.

Ik snap wat dat betreft de voorbeelden van HD-DVD en Bluray ook nooit. Wat betekent dat? Dat Bluray nooit had mogen bestaan omdat HD-DVD de logische volgende versie is van de DVD? Of geldt wie het eerst een persbericht uitstuurt? Of wie het eerst de standaard deponeert? Of wie het eerst een officiele standaard status heeft (bijv. ECMA of ISO)? En betekent dat dan dat Holodisc dan nooit meer een standaard kan worden omdat het nu te laat is?
De vergelijking raakt kant-noch-wal...

Standaardisatie zou nooit een race mogen worden wie het eerst ECMA, OASIS of ISO gecertificeerd is. Dat zou innovatie alleen maar belemmeren. Open XML is al jaren in ontwikkeling. Je maakt niet zomaar van de een op de andere dag een XML gebasseerd documentformaat. Een van de design criteria van Open XML was dat het nieuwe formaat optimaal compatibel moest zijn met de letterlijk miljarden bestaande documenten in het binaire bestandsformaat (DOC, XLS, PPT). Klanten eisen dit van Microsoft. Geen enkele MS Office gebruiker zit te wachten op een nieuw bestandsformaat dat niet optimaal compatible is met het oude formaat.

Aan de andere kant roepen overheden, commerciele bedrijven, ontwikkelaars en vooral concurrenten al tijden dat Microsoft haar bestandsformaten moet vrijgeven. Dat hebben we nu gedaan met Open XML. Open XML wordt gecontroleerd en beheerd door ECMA en niet door Microsoft. Er is een covenant-not-to-sue die gebruikers en ontwikkelaar (incl. concurrenten van Microsoft) vrijwaart van juridische aansprakelijkheid inzake patentschending. Dit is een vergelijkbare CNS die Sun heeft opgesteld voor Sun patenten in ODF. Hierdoor kan iedereen een Open XML implementatie schijven. Voorbeelden hiervan (160+) zijn hier te vinden: link (inbegrepen bekende toepassingen zoals Apple iWorks08, Corel WordPerfect Office, Gnumeric, MindJet MindManager, Open Office - Novell edition)

Open XML is ontwikkeld om de rijke functionaliteit van Microsoft Office te representeren terwijl ODF is ontwikkeld om de functionaliteit in OpenOffice te representeren. Het aanpassen van ODF om aan dit design criterium te voldoen was technisch en politiek onhaalbaar. Zie ook onderstaande quote van Gary Edwards (President OpenDocument Foundation):

quote: "If Micrsoft were to join the OASIS ODF TC today, seeking to adapt ODF to meet the legacy document-MSOffice features-line of business integration needs of their monopoly base, the TC would have to deal with the exact same issues as they have summarily rejected with current compatibility-interoeprability-convergence disussions!

There is no possible way anyone can claim that today's OASIS ODF TC would welcome Microsoft and make accomodating changes to the specification! No way! And the proof of this hostility can be seen in the actual disussions and rejections of Micrsoft specific interoperability proposals"

-opmaak aangepast-

[Reactie gewijzigd door Raul Pesch op 24 juli 2024 21:39]

[kidde]

Een van de design criteria van Open XML was dat het nieuwe formaat optimaal compatibel moest zijn met de letterlijk miljarden bestaande documenten in het binaire bestandsformaat (DOC, XLS, PPT).

OpenXML is niet compatibel aan de miljarden bestaande documenten. Zowel .doc, .xls als .ppt zijn niet in OpenXML gespecificeerd en blijven zo gesloten als altijd al het geval is geweest. Alleen Microsoft-software kan deze oude formaten fatsoenlijk omzetten naar open XML formaten. Kortom, OpenXML is niet compatibel met oude formaten; heel het compabiliteitsverhaal is een reclamepraatje om te rechtvaardigen dat Microsoft willens en wetens haar klanten op kosten jaagt door verschillende ISO-standaarden voor hetzelfde doel na te streven (hetzelfde dat zal gaan gebeuren met PDF).

Microsofts Klanten zijn erbij gebaat dat het .doc, .xls en .ppt formaat opengesteld worden, niet dat ze de gedwongen worden de nieuwste versie van Microsoft Office te moeten kopen om hun oude bestanden te kunnen converteren. De bestaande lock-in blijft vooralsnog dus bestaan - ondanks OpenXML - en dat is wat innovatie stopt. Tevens is het vooralsnog de vraag of Microsoft Office echt wel in het OOXML opslaat dat nu bij de ISO ligt, de nieuwste versie van Microsoft Office heeft daar geen compabiliteitsmodus voor volgens ingewijden (bron).

Ik snap wat dat betreft de voorbeelden van HD-DVD en Bluray ook nooit.

Dat komt omdat u moedwillig standaarden in het algemeen en ISO standaarden in het bijzonder door elkaar haalt, en hoopt dat de lezers daar in trappen. Over het algemeen zijn de lezers hier echter niet zo dom.

Het is niet erg (wel hooguit vervelend) als er honderd standaarden voor hetzelfde doel, bijvoorbeeld video-codecs zijn. Doel van standaardisatie (de reden dat het eerste standaardenorgaan - de DIN - werd opgericht) is om geld te besparen en gevrijwaard te blijven van patentclaims. Alle verschillende videoformaten (standaarden) lijden tot kostenstijgingen en patentproblemen (zoals MP3/Microsoft die bijna honderden miljoenen moest betalen voor licenties op dit audioformaat). Dat Windows-kopers minstens 5 euro betalen om die tientallen verschillende formaten te mogen gebruiken, en ook nog eens betalen voor de overheadkosten van het uitgeven van licensties onderling tussen bedrijven + bijkomende juridische kosten, was niet nodig als er 1 enkele ISO standaard was voor videoformaten. Dat laatste had vooral Microsoft een hoop geld gescheeld.

En waarschijnlijk trappen mensen die ISO-standaarden kennen ook niet in de 'convenant not to sue': Het spreekt voor zich dat iedereen zonder hoge drempel (zoals patentlicenties) ISO-standaarden moet kunnen implementeren. Als dat niet zo is, zou zo'n standaard geen ISO-standaard hebben mogen worden in de eerste plaats. Nogmaals; het idee van ISO-standaarden is om kosten te besparen, niet om tientallen miljoenen aan juridisch advies kwijt te zijn. Het is al schandalig dat een dergelijk convenant op ISO26300 (ODF) van toepassing is, en dit herhalen zou helemaal verkeerd zijn.

-ED: Over het verhaal over standaardiseren op autogas: Gelukkig zijn brandstoffen inderdaad gestandaardiseerd. Dit zodat als u Euro95 moet tanken, u zeker weet dat de fabrikant van uw auto niet een andere norm voor Euro95 heeft gevolgd dan uw tankstation. Was dit wel het geval, dan zou u al snel langs de kant van de weg staan, en wederom op kosten gejaagd worden door meerdere standaarden voor hetzelfde doel. Gelukkig echter heeft de industrie, in tegenstelling tot Microsoft, het goed met u voor, en gebruikt iedereen een en dezelfde standaard, om u kosten en ellende te besparen.

[Reactie gewijzigd door kidde op 24 juli 2024 21:39]

[Raul Pesch]

Kidde, bedankt voor je uitgebreide uiteenzetting van punten. Er zijn een aantal zaken waarop ik wil reageren:

Microsofts Klanten zijn erbij gebaat dat het .doc, .xls en .ppt formaat opengesteld worden, niet dat ze de gedwongen worden de nieuwste versie van Microsoft Office te moeten kopen om hun oude bestanden te kunnen converteren.

Dat hoeft helemaal niet. Klanten met oudere versies van Office kunnen het gratis compatibility pack downloaden waarmee ze met hun bestaande Office versie gebruik kunnne maken van het nieuwe bestandsformaat en oude bestanden -indien gewenst- kunnnen converteren: http://office.microsoft.c...ducts/HA101686761033.aspx

Dat komt omdat u moedwillig standaarden in het algemeen en ISO standaarden in het bijzonder door elkaar haalt, en hoopt dat de lezers daar in trappen. Over het algemeen zijn de lezers hier echter niet zo dom.

Ik refereer naar een aantal suggesties (in deze thread notabene) waar lezers suggereren dat er nooit twee standaarden hadden mogen bestaan voor High Definition DVD's. Mijn voorbeeld is om te illustreren dat het heel lastig is om dat te voorkomen aangezien verschillende standaarden ieder zijn eigen voor- en nadelen heeft.

Om met een ISO voorbeeld te spreken, er zijn veel verschillende ISO standaarden voor vergelijkbare standaarden:
muziek: MP3, AAC
images: JPEG, PNG
video: MJPEG, MPEG-1, MPEG-2, MPEG-4, H.264
programmeertalen: Fortran, Cobol, C, C++, C#, Extended Pascal, Full Basic, Prolog, Eiffel, ISLISP

Alle verschillende videoformaten (standaarden) lijden tot kostenstijgingen en patentproblemen (zoals MP3/Microsoft die bijna honderden miljoenen moest betalen voor licenties op dit audioformaat). Dat Windows-kopers minstens 5 euro betalen om die tientallen verschillende formaten te mogen gebruiken, en ook nog eens betalen voor de overheadkosten van het uitgeven van licensties onderling tussen bedrijven + bijkomende juridische kosten, was niet nodig als er 1 enkele ISO standaard was voor videoformaten.

MP3 is reeds een ISO formaat... ondanks dat waren er de genoemde problemen.

En waarschijnlijk trappen mensen die ISO-standaarden kennen ook niet in de 'convenant not to sue': Het spreekt voor zich dat iedereen zonder hoge drempel (zoals patentlicenties) ISO-standaarden moet kunnen implementeren. Als dat niet zo is, zou zo'n standaard geen ISO-standaard hebben mogen worden in de eerste plaats.

Sun heeft een vergelijkbare Covenant Not to Sue voor ODF en desondanks is ODF een ISO standaard geworden. Een vergelijking tussen onze CNS en Sun's CNS voor ODF staat hier: link

Nogmaals; het idee van ISO-standaarden is om kosten te besparen, niet om tientallen miljoenen aan juridisch advies kwijt te zijn.

Zie mijn eerdere opmerking over MP3.

Microsoft heeft de CNS juist uitgegeven om precies te bewerkstelligen wat je suggereerd: de garantie geven dat er geen onverwachte juridisch kosten of patentbeperkingen opgelegd kunnen worden. Onze ODF is een algemene vrijwaring die voor iedereen geldt (ook voor concurrenten). Nogmaals, hetzelfde is het geval met Sun inzake ODF.

[kidde]

Klanten met oudere versies van Office kunnen het gratis compatibility pack downloaden.

Mijn fout dat ik dat niet wist, chapeau aan Microsoft en prettig voor de klanten.

Als MP3 enz. inderdaad ISO standaard zijn, had dat mijns inziens niet gemoeten wegens de patentproblemen (die al redelijk bekend waren), net als met ODF en het convenant not to sue (zoals ik reeds zei in mijn eerdere reactie). Dat het desondanks in het verleden toch vaak mis is gegaan is een extra reden om dezelfde fout niet nogmaals te maken lijkt me. Om nog nader toe te lichten: Van wat ik o.a. van Tweakers heb begrepen is ISO26300/ODF ook niet ideaal, en is de standaard deels gemaakt om de belangen van Sun veilig te stellen. Toch zou het wenselijk zijn deze standaard zo te veranderen dat de wensen van klanten voorop staan, en juist Microsoft zou daar - alsnog -een grote bijdrage aan kunnen leveren. Dat het in het verleden mis is gegaan is erg jammer, maar het wordt tijd dat zowel IBM, Sun als ook Microsoft (en Corel, Haansoft e.a.) _samen_ met als uitgangspunten de wensen van de gebruikers _1_ ISO standaard maken.

Ik snap dat het lastig is tot een standaard te komen zonder naar patenten te kijken (de halve software-wereld zit dichtgepatenteerd), en daarom is het fijn dat er een CNS is, maar in de ideale wereld zouden alle ISO standaarden vrij van patentproblemen moeten zijn. Het niet afdwingbaar maken van software-patenten lijkt me daar een belangrijke bijdrage aan. Het zou goed zijn als Microsoft zich daarvoor zou inzetten, want Microsoft en haar klanten wordt nu meer de dupe van patenten dan dat het Microsoft en haar aandeelhouders wat oplevert, zo lijkt het voor buitenstaanders.

Voor de meeste 'oudere' normen ( ruwweg <DIN5000) zijn er voor zover mij bekend bijvoorbeeld weinig tot geen patentbelemmeringen; en dat is een van de redenen dat de 'oude' industrie zo efficient werkt.

[Reactie gewijzigd door kidde op 24 juli 2024 21:39]

[Raul Pesch]

Kidde, ik kan me grotendeels in je punten vinden.

Juridisch gezien is Open XML echter al vrij van patentproblemen. De CNS zorgt daarvoor. Deze is tevens perpetual (eeuwigdurend) en non-revocable. Microsoft kan dus nooit eenzijdig de CNS intrekken of veranderen. Klanten, partners en concurrenten van Microsoft kunnen Open XML implementeren in de wetenschap dat eventuele patenten daarin niet tegen hun gebruikt zullen worden (ook als ze een gedeeltelijke implementatie van Open XML doen).

Ik ben het met je eens dat alle ISO standaarden een soortgelijke garantie moeten bieden en volgens mij is dat tegenwoordig ook het geval bij ISO certificaties.

[Little Penguin]

Dat hoeft helemaal niet. Klanten met oudere versies van Office kunnen het gratis compatibility pack downloaden waarmee ze met hun bestaande Office versie gebruik kunnne maken van het nieuwe bestandsformaat en oude bestanden -indien gewenst- kunnnen converteren: http://office.microsoft.c...ducts/HA101686761033.aspx

Mijn klanten maken nog gebruik van Office'97, kunnen zij gratis upgraden naar een versie die wel OOXML ondersteund?

Veel bedrijven zullen verder niet zo snel een OOXML of ODF converter/plugin installeren, waardoor OOXML effectief dus helemaal niet zo'n groot marktaandeel heeft/kan krijgen als gesuggereerd wordt.

[Verwijderd]

Het MS compatibility pack kun je in een Office 97 omgeving wel gebruiken als zelfstandige converter maar niet integreren in Office 97.
Bedrijven zullen de plugin wel installeren maar vermoedelijk pas in de loop van volgensd jaar.
Het ligt echter wel voor de hand dat MS compatibiliteit in een Office service pack stopt. daarmee zullen ze vermoedelijk wel wachten tot de herzieningen die uit de ISO standaardisatie voortkomen zijn doorgevoerd.

[Verwijderd]

Zeker mogen er meer defacto standaarden bestaan, maar het is niet de taak van ISO om dit te stimuleren. De taak van ISO is ervoor te zorgen dat er een zo breed mogelijk draagvlak komt voor een enkele standaard, en dat die standaard voldoet aan bepaalde kwaliteitsnormen.

We zien ook dat redundante standaarden eerder lastig zijn dan een voordeel, kijk naar de verschillende DVD-standaarden, inmiddels hebben de meeste fabrikanten ondersteuning moeten inbouwen voor alle marrktvariëteiten. Dit werkt kosten verhogend voor de consument, omdat de fabrikant licentiekosten moet doorberekenen, en de verschillende DVD-standaarden bieden nauwelijks voordeel ten opzichte van elkaar.

Dit is ook voor de Office-standaarden zo, uiteindelijk zullen ze alleen maar lastig worden, want de applicatiebouwers zullen meerdere standaarden simultaan moeten gaan ondersteunen, dit kost gewoon geld, dat de consument moet gaan betalen.

In het belang van de klant was geweest dat Microsoft samen met Oasis aan ODF had gewerkt. Dat is ook de koninklijke weg binnen ISO.

Het veel aangehaalde citaat van Gary Edwards wordt veelal verkeerd begrepen. MS wil de Office standaard vervuilen met allerlei proprietary zaken die neit in een vendor onafhankelijke standaard thuis horen, ik noem een paar voorbeelden zonder compleet te willen zijn, in OOXML komen volgende tags voor: autospacinglikeword95, useWord97LineBreakRules, useWord2002TableStyleRules.
Dan is er het issue dat in OOXML het jaar 1900 een schrikkeljaar dient te zijn, dit in tegenstelling tot de werkelijkheid. En nog veel meer zaken die MS vanwege haar eigen applicaties in een vendor-onafhankelijke standaard wil proppen.

Dit is inderdaad niet acceptabel, en ik hoop dat ISO hierover valt. MS heeft gewoon slechte specificaties geschreven. Compatibilteits-issues naar legacy hoor je niet binnen een standard op te lossen, daarmee wil je andere vendors niet belasten. Dat soort dingen moet je extern middels tooling regelen.

Ik hoop dat ISO gaat besluiten dat OOXML geen ISO erkenning waardig is, en ik verwacht dat Microsoft, dan gezien de nieuwe situatie wel moet gaan samenwerken met de andere ISO standaard die bijna automatisch dan de keuze wordt van overheden, en dat MS haar legacy problemen dan in haar eigen software gaat oplossen

[Verwijderd]

Ik denk dat jij het citaat van Gary edwards verkeerd begrijpt.

Hij heeft het over voorstellen van binnen de OASIS TC voor compatibiliteit met MS formaten die door Sun/OOo worden afgewezen.

Dat heeft dus volstrekt NIETS te maken met voorstellen van Microsoft of genoemde comaptibiity items in Office open XML.

En als Micrsoft hun compatibility met legacy documenten met tooling en propriety extesies regelt (zoals OOo met hun legacy bugs doet) en deze dus voor andere vendors volstrekt ontoegangelijk is dan wordt iedereen boos dat Microsoft een vendor lock-in gebruikt om hun producten te verkopen.

[Verwijderd]

Hij heeft het over voorstellen van binnen de OASIS TC voor compatibiliteit met MS formaten die door Sun/OOo worden afgewezen.
Dat is precies wat ik zei, althans bedoelde.

het lijkt mij een slechte zaak indien een vendor-onafhankelijke ISO standaard wordt gebruikt om bugs en vendor-gebonden tags te implementeren. Stel je voor dat andere Ecma-leden ook hun tags erin kwijt willen, want de standaard is van Ecma, Ecma staat proprietary tags kennelijk toe, en waarom dan niet van anderen?

De standaard wordt een rommeltje van proprietary-tags Het precedent is immers door Ecma-lid Microsoft gezet.

En dan heb ik het nog niet eens over de bugs die OOXML implementeert, bugs bewust in een ISO standaard zetten, en alle applicaties vragen om een workaround voor deze bug te schrijven?

[cygnusfear]

Waarom niet standaardiseren op 1 soort brandstof: alleen nog maar autogas?
Er zijn redenen te bedenken waarom sommige mensen liever op benzine of diesel rijden.

Wat een prachtige allegorie, vooral een erg irrelevante. We hebben het hier over een communicatiemiddel, geen brandstof. Het is spijtig, maar dit raakt kant nog wal.

Er valt veel te zeggen voor een standaard, voornamelijk dat iedereen in staat gesteld moet worden om gebruik te maken van de desbetreffende 'drager', of dit nu de taal Nederlands is, een CD-ROM of het signaal van een Mobiele telefoon. Wanneer er discrepanties in de communicatie opsteken hebben we te maken met de hyper-moderne 'toren van Babel'.

Om kort te blijven, jij hebt liever dat je alle providers kan bellen omdat iedereen hetzelfde mobiele signaal gebruikt, en niet alleen de mensen die dezelfde provider hebben als jij toch? Daar is een standaard mee te vergelijken, één gestandaardiseerde vorm van communicatie.

Geen enkele MS Office gebruiker zit te wachten op een nieuw bestandsformaat dat niet optimaal compatible is met het oude formaat.

Verwerk backwards compatibiliteit in een tekstverwerkingsprogramma, niet in een standaard.

Standaardisatie zou nooit een race mogen worden wie het eerst ECMA, OASIS of ISO gecertificeerd is

Vanwaar zou het een race zijn? Het gaat er om dat er waar mogelijk duidelijkheid is over een standaard, waar aandacht besteed moet worden aan de vragen of deze waarde heeft en niet binnen al te korte tijd vervangen hoeft te worden. Is er geen standaard, dan krijgen we een situatie als met de videobanden, minidisc, letter/a4 problemen. Zelfs ons metrieke systeem is een standaard, verschillende metrieke systemen leveren nog altijd problemen op.

Wanneer heeft het zin om verschillende standaarden naast elkaar te gebruiken? Als deze een expliciet andere functie hebben, waardoor beide standaarden misschien een 'overlap' hebben maar toch dermate exclusieve eigenschappen dat het waardevol is. Daar zou de discussie rond OOXML over moeten gaan.

quote: "If Micrsoft were to join the OASIS ODF TC today, seeking to adapt ODF to meet the legacy document-MSOffice features-line of business integration needs of their monopoly base, the TC would have to deal with the exact same issues as they have summarily rejected with current compatibility-interoeprability-convergence disussions!

En dit is nu exact het probleem, 'legacy' 'line of business integration needs of their monopoly base' geen enkele plaats heeft in een standaard. A4 wordt niet gebruikt door een bedrijf om een marktpositie te behouden, alhoewel er genoeg papier gemaakt wordt dat de aanduiding gebruikt. Dat is een standaard, en daar gaat het nu over.

edit:
woordjes weg, poef

[Reactie gewijzigd door cygnusfear op 24 juli 2024 21:39]

[Little Penguin]

Een van de design criteria van Open XML was dat het nieuwe formaat optimaal compatibel moest zijn met de letterlijk miljarden bestaande documenten in het binaire bestandsformaat (DOC, XLS, PPT).

en om deze compatibeliteit te bereiken worden bugs klakkeloos gekopieerd? Worden features beschreven in de vorm van 'FeatureXLikeWordY'?

Dat kan ik niet echt een vooruitgang noemen, het minste wat je kan doen bij zo'n nieuw formaat is het verwijderen van bugs. Door bij het opslaan in het nieuwe formaat aan te geven dat er bepaalde features verwijderd/aangepast zijn kun je de gebruiker hierop wijzen. Op die manier krijg je 99% compatibiliteit (genoeg voor de meeste mensen en bedrijven) en toch een standaard die je ook over 15 jaar nog zinnig kan interpreteren.

Hetzelfde geld voor de verwijzingen naar bepaalde office applicaties, die zorgen misschien wel voor compatibiliteit, maar het is beter om exact te beschrijven wat die feature inhoud.

Klanten eisen dit van Microsoft. Geen enkele MS Office gebruiker zit te wachten op een nieuw bestandsformaat dat niet optimaal compatible is met het oude formaat.

Ik denk dat, als klanten applicaties willen laten schrijven die XML based office formaten kunnen aanmaken, ze liever een goed doordacht formaat hebben wat tot in de puntjes open en duidelijk is, dan een formaat waar eerst uren en uren aan reverse enginering gedaan moet worden om precies te bepalen hoe het in elkaar zit...

[Verwijderd]

waarom heeft Microsoft een nieuwe standaard ontwikkeld en niet ODF uitgebreid?

Omdat (volgens de opendocument foundation !!) ODF ontwikkeling volledig in de pocket zit van Sun/OOo en het daardoor niet mogelijk is om daar features lang te krijgen die ze niet in OpenOffice/StarOffice willen ondersteunen.

[Pietervs]

En jij denkt dat MS wel zaken die zij niet in Office terug willen zien gaat ondersteunen in OOXML? Sorry, maar dat lijkt mij sterk.
Cariolive23 heeft gelijk: verdeel en heers. MS is een bedrijf, en zal geld willen maken (zoals een goed non-profit bedrijf hoort te doen). Het doorgaan van OOXML is voor hun dus belangrijk: daarmee hebben ze een knappe troef in handen richting de vele bedrijven en overheden die op dit moment overwegen om over te stappen op OpenOffice vanwege ODF.

[Verwijderd]

Nee dat denk ik zeker niet. Maar in dat geval hebben zijn gebruikers van MS Office dus een belangrijk voordeel bij OOXML ISO standaardisatie.
Zij zijn dan veel minder afhankelijk van de nukken van software bouwers en kunnen wel hun volledige functionaliteit behouden wat toch over het algemeen de reden is warom ze voor MS Office gekozen hebben.

[Maurits van Baerle]

Er is inderdaad een bij tijd en wijlen oplaaiend verschil van visie tussen enerzijds de OASIS TC (die de ODF standaard ontwikkeld) en anderzijds de OpenDocument Foundation (een advocacy groep).

Het verschil in visie komt er in de praktijk op neer dat OASIS een standaard wil die technisch zo goed mogelijk is en daarmee ook trendsettend. Applicaties zullen aangepast of uitgebreid moeten worden om hier aan te voldoen. Sommige zaken worden bijvoorbeeld nu nog niet, of maar beperkt, toegepast in Office suites.
De OpenDocument Foundation daarentegen vindt uitwisselbaarheid met MSOffice van het allergrootste belang. Meestal bijten deze twee visies elkaar niet maar af en toe wil bijvoorbeeld OASIS een functie toevoegen of uitbreiden die niet in MS Office beschikbaar is. De OpenDocument Foundation is hier dan op tegen. Zij willen een plugin uitbrengen die een 100% round-trip mogelijk maakt tussen OOXML en ODF. Als ODF dan meer ondersteund dan OOXML treedt er ergens mogelijk data-verlies op.

Het is op zich een heel interessante discussie waar van beide kanten wel iets voor te zeggen valt.

[Reactie gewijzigd door Maurits van Baerle op 24 juli 2024 21:39]

[cariolive23]

Lijkt me duidelijk dat het veel handiger is om een enkel standaart te hebben.

Wanneer MS jouw salaris betaalt, dan piep je wel anders.

Verdeel en heers, gaat ook op in de IT-wereld en MS heeft geen enkel belang bij een standaard die niet door hen is uitgevonden. Zij zijn de standaard!

(zou ik ook denken/roepen wanneer ik MS was)

MS heeft een ISO-standaard nodig om regeringen en grote bedrijven tevreden te houden. That's all.

[Cameleon73]

Een erg belangrijke vraag is: hebben we inderdaad baat bij meerdere document standaarden? Zoals al veel is onderzocht is (lees b.v. deze 16 pagina's tellende PDF maar 'ns), is dit niet alleen een kwestie van 'hoe meer keuze, hoe beter'.

Een voorbeeld is b.v. de standaardisatie van het stroomnet (waarbij je ziet dat -zodra je meerdere standaarden hebt- er gelijk problemen ontstaan: 110V en 230V), of het wegen- en railsnetwerk. Hier geldt zeker niet: hoe meer standaarden, hoe beter.

Omdat we het hier hebben over informatie uitwisseling, lijkt me dit een zorgvuldige overweging waard (bij voorkeur niet besloten binnen 30 dagen...)!

[cygnusfear]

Het blijft een interessant onderwerp, voornamelijk omdat voorheen een bedrijf wat zeer grote macht pretendeerde te hebben in de wereldeconomie (microsoft) langzaam ziet dat haar bedrijfsmodel niet meer het gewenste resultaat oplevert. Daardoor met man en macht gaat innoveren wat haar bedrijfsmodel betreft. Ik heb veel respect voor hoe gigantisch goed Microsoft microsoft is in het exploiteren van (de) globale economie.

Helaas is het over het algemeen van bedrijven geoorloofd om alle moraal te laten vallen (insert allegorie over broodwinning).

De volgende PDF (direct van de 'tegenpartij', let wel) heeft een aantal interessante verwijzingen naar het proces in de rest van de wereld.

http://www.noooxml.org/lo...nts/ODF-vs-OOXML-v1.2.pdf

Volgensmij heeft de desbetreffende Wouter van Vugt hier meerdere malen gereageerd in vorige topics en mocht ik het goed gelezen heb is hij een voorstander van de ISO standaard.

The first thing one of us tried to do was keep in touch with the overall process, which was really great since it's easy to go back to name-calling and saying that the tag name 'paragraph' is much cooler than 'p', a level we need to rise above to be productive. So the process of the Dutch committee would be to first go through the comments and get to those that we agree upon, and their wording of course. Next these comments could be tied to the vote still to come.

http://blogs.infosupport....or-the-Open-XML-ISO-.aspx

Uit de tekst op zijn blog kan men aardig destilleren wat voor figuren er hier beslissingen maken. Daarnaast vervolgt zijn blog met het feit dat er weinig 'technische bezwaren' zijn. Omdat het specifieke 'formaat' dus eigenlijk irrelevant is en technisch in orde blijkt te zijn, vervolgt de rest van de discussie daar;

A 'conditonal-approve' is still a DISAPPROVE in my book, and the slides demonstrated before the meeting started also noted that there will be no BRM or Open XML ISO standard if more than I believe 1/4th of the votes are a DISAPPROVE. The difficulty is not this initial vote, but the unclearness of ISO in the allowed moves when the BRM takes place. The delegation going to ISO is rather powerful. They have to see whether the comments were addressed properly and the move from DISAPPROVE to APPROVE, but can you be sure this will happen? Personally

So all in all, it totally sucks. You cannot reach a conclusive and useful vote if there is no trust between parties. I feel that some people have much to do with that feeling of untrustworthiness given their campaign and open statements of wanting to block Open XML no matter what.

Vergeleken met de inhoudelijke discussie over de standaard vind ik dit weer het typische gebrek van een dergelijke commissie. De commissie heeft namelijk een discussie gehad over wat de stemmogelijkheden in hielden, en niet wat het formaat inhield. Zodoende kan ik niet treuren over het oordeel, laten we maar gewoon niks zeggen want

Naar mijn bescheiden mening had onze ISO commissie ook even stil mogen staan bij wat een ISO commissie inhoudt, wat het exacte 'doel' is van een ISO standaard. Het gaat namelijk niet alleen over of een formaat conformeert aan de ISO standaard, wat ook van belang is of het nodig is twee verschillende co-existerende standaarden te hebben. Wat mij betreft zie ik toch wat meer 'sense' in de Indische ISO commissie (en tegelijk ook de bias, natuurlijk)

But this is relevant to India. India cannot afford to create a situation where interoperability becomes a PAIN. Standards adoption process should evolve into a PAINless situation, and not a possible situation. Therefore, acepting multiple standards
for the same task is not going to give India a desirable situtation. Knowing fully well, inviting trouble is stupidity. Therefore, saying that such an important question is irrelevant
to ISO process is not an acceptable answer. We have to assess, whether inviting multiple standards is good for the country or not?

http://www.odfalliance.in...es%20from%20Nagarjuna.pdf

Zodoende blijft het interessant, naar mijn mening had de commissie inderdaad een beter oordeel kunnen vellen wanneer niet al haar tijd besteed was aan wat de verschillende 'stemmen' inhielden (en dit vooraf een keer was besproken) en wanneer iedereen de standaard ook echt bestudeerd had; dan had het gesprek over de 'waarom ftlog zou het een ISO standaard moeten worden' boeg gegooid kunnen worden en zou men beseffen dat er wel degelijk technische bezwaren waren.

edit:
linkje, spelling

[Reactie gewijzigd door cygnusfear op 24 juli 2024 21:39]

[Verwijderd]

Ik ben behoorlijk geschokt dat deze duur betaalde mensen moeten stemmen over een standaard en dan komen met commentaar als: "er bestaat al een standaard, namelijk odf". Ja hallo, de diskette en cd bestaan ook al, waarom zouden we in godsnaam dan bly-ray of hddvd standariseren , het is dezelfde redenatie. Ook OOXML is op sommige punten een vooruitgang ten op zichte van ODF (En andere punten misschien niet (Voordat iedereen daar weer over begint), maar ja omgekeerd ook. Perfect bestaat immers niet).

Ik vind dit wel erg kortzichtig van de betrokkenen... Het idee van een iso standaard is, is dat je 100% mag aannemen dat de implementatie is zoals beschreven en dat je deze mag implementeren en dat door iedereen op een uniforme manier gebeurd. Nergens staat dat er maar 1 standaard van iets mag zijn. Ja, je moet inderdaad niet te veel verschillende standaarden krijgen, bij 5 document standaarden raak je inderdaad de weg wel kwijt, maar bij 2 echt niet.

Ik heb meer het idee dat die groep een stel ego's bij elkaar is die hun mening doorgedreven moeten hebben en niet willen compromiseren. Want ook bij die "ja mits" en "nee mits" kun je de mits nog zo zwaar formuleren dat het haast een onmogelijke taak zou zijn. Maar dan praat je in elk geval nog gewoon mee....

[Reactie gewijzigd door Verwijderd op 24 juli 2024 21:39]

[kidde]

Blu Ray en HD-DVD zijn geen ISO standaarden. Het idee van ISO standaarden is dat het de industrie geld bespaart.

Vroeger hadden de Britten, Duitsers en Amerikanen hun eigen maten schroefdraden/flenzen etc. Duitse pijpen pasten niet op Amerikaanse pijp-flenzen, Britse boutjes niet op Duitse moertjes, en een leverancier van NASA leverde maten aan in het imperiale stelsel wat NASA in SI-eenheden implementeerde, wat ertoe leidde dat een mars-karretje van 1 miljard dollar naar de klote ging. De standaard ERTMS was bedoeld om geld uit te sparen voor treinbeveiligingssystemen doordat meerdere standaard voor hetzelfde doel (per land een aparte) door een standaard vervangen werden, maar het niet voldoen van ERTMS aan de gestelde eisen - en de veranderende eisen (meningen verschillen) hebben tot grote kostenoverschrijdingen geleverd.

Het is dus gebleken dat het de eindgebruikers - met name de industrie - miljarden kost, en ongelukken gebeuren door meerdere standaarden met hetzelfde doel.

In plaats van daarvan te leren, en haar klanten miljarden te besparen, komt Microsoft met een nieuw formaat voor hetzelfde doel, waardoor er net zoals nu nogsteeds omgerekend moet worden tussen inches en centimeters, er over tientallen jaren nog geconverteerd zal moeten worden tussen verschillende standaarden. Dit levert een hoop extra werk, kosten, fouten en risico's op voor de klanten van Microsoft. Daarom is de 'oude' (metaal)industrie ook overgestapt op 1 standaard voor 1 doel; en mede daarom wordt in die oude industrie veel minder geld verspild in projecten dan de miljarden in IT-projecten.

Kortom, in plaats van dezelfde fout te maken als de 'oude' industrie decennia geleden, kan Microsoft beter leren van de wensen van de klant in plaats van deze met miljarden aan extra kosten op te zadelen.

IT-service leveranciers (zoals er twee in de NEN-commissie zaten) zal je hier niet over horen klagen, zij zijn degenen die de projecten binnenslepen en veel geld verdienen door de verschillende contradicterende standaarden te converteren. Het resultaat is duidelijk: De klant betaalt deze historische blunder van Microsoft.

[Reactie gewijzigd door kidde op 24 juli 2024 21:39]

[Fuzzillogic]

Te kort door de bocht. ODF en OOXML zijn directe concurrenten van elkaar. Net zoals HDDVD en Bluray. Ik denk niet dat de wereld gebaad is bij zulke dubbele standaarden. Dat geldt voor HDDVD/BR, maar nog meer voor een officedocument-standaard.

[Quacka]

overschatten we hier niet een beetje de invloed van nederland?
Uiteindelijk heb je als relatief klein land volgens mij vrij weinig te zeggen. Al kan ik me wel voorstellen dat je beter een nee met een aantal punten voor kan leggen, dan een onthouding. Dat laatste is natuurlijk helemaal nietszeggend.
Maar ik denk niet dat bij een "nee, mits" nederland opeens zijn zin zou krijgen..

[Verwijderd]

overschatten we hier niet een beetje de invloed van nederland?


Waarvoor stemmen we dan nog? 1 persoon heeft toch niks te zeggen

[Raul Pesch]

Bij een ISO standaardisatie proces heeft iedere "Participating Member" een gelijkwaardige stem. Nederland is een participating member en de Nederlandse stem weegt dus net zo zwaar als bijvoorbeeld Amerika, Duitsland, Frankrijk of Engeland.

Het is zonde dat er geen overeenstemming gekregen kon worden voor een "approval with comments" stem aangezien al het werk wat in Nederland gedaan is nu verloren gaat en wij geen deel meer uitmaken van het verdere proces.

Onze kijk op de gang van zaken:
The Netherlands vote on Open XML
One Sided

Raul Pesch
Microsoft

[kidde]

Daar voeg ik graag aan toe, de kijk van Michiel Leenaars op de gang van zaken met betrekking tot het gedrag van Microsoft in dezelfde gang van zaken:

Er zijn geen technische redenen aangegeven en daarom kan de persistente blokkade van deze stemming als een tactisch en voorafbepaald standpunt worden beschouwd- het best gekaracteriseerd door het feit dat Microsoft-medewerkers vlak voor de vergadering journalisten al hadden verteld dat Nederland zich van stemming zou onthouden.

[Reactie gewijzigd door kidde op 24 juli 2024 21:39]

[Verwijderd]

Dan haal ik er dit stukje nog even bij uit dezelfde pagina.

Een eis die aan iedere Fast Track procedure gesteld moet worden is dat er ten minste twee interoperabele en onafhankelijke volle implementaties van een ingebrachte standaard zijn alvorens deze geaccepteerd kan worden.

Het een beetje een slechte quote omdat de context niet duidelijk is maar dit zou dus een aanpassing zijn aan de Fast Track procedure die men graag zou willen zien.

Daar ben ik het 100% mee eens. Stel je voor dat MS Office en OpenOffice allebij een compleet werkende en compatibele implementatie zou hebben van dit Open XML formaat die bij voorkeur nog helemaal uit de officiele specificatie is gemaakt.

Dan zou Open XML van mij absoluut een officiele ISO standaard mogen worden ookal is die er eigenlijk al in de vorm van odf. Ten eerste is er niks mis met meerdere standaarden zolang er niet sprake is van vendor-lockin en je gewoon vrij bent te kiezen welk formaat je wil gebruiken.

Ik hou van de BSD varianten en een beetje ook van Linux maar Windows ben ik ook heel heel tevreden en gelukkig mee met uitzondering van Vista maar dat is smaak en misschien ook tijdelijk. Toch vind ik inderdaad dat het gedrag van Microsoft niet helemaal goed zit in deze zaak.

Vooral heb ik het idee, ookal kan ik het mis hebben, dat Microsoft dit formaat meer ziet als een markt strategie dan iets wat gebruikers echt willen en nodig hebben. Volgensmij hebben ze absoluut geen intresse in een echte open standaard die iedereen kan implementeren. Ik denk eerder dat ze een "open" standaard willen zodat ze aan iedereen, vooral bijvoorbeeld regeringen, kunnen laten zien hoe goed ze zijn.

Maar dat wanneer het er op aan komt dat een document geschreven in word er compleet anders uitziet in bijvoorbeeld openoffice maar bijvoorbeeld omgekeerd weer niet. Omdat OpenOffice niet gebruik maakt van dingen als TabsLikeWord97.

Dat laatste woord heb ik even puur uit mijn herinneringen dus er zal waarschijnlijk wel niet letterlijk zoiets in zitten maar wel iets waar dit op neer komt.

[Raul Pesch]

Er is reeds een hele waslijst (160+) van applicaties op het Windows, Mac en Linux platform die Open XML ondersteunen. De meest recente toevoegingen zijn Apple iWorks en de iPhone.

Nu beschikbaar:
Apple iPhone
Apple iWorks08
Corel WordPerfect Office
Gnumeric
Linspire Open XML translator
Microsoft Office 2000, XP en Office 2003
Microsoft Office 2007
MindJet MindManager
Neo Office 2.1
OpenOffice - Novell edition

Binnenkort beschikbaar:
PhytonOffice
Sun Open XML import filter for Calc
Xandros Desktop Home edition
Microsoft Office 2008 for Mac
Sun StarSuite 8

en meer: http://www.openxmlcommunity.org/applications.aspx

[Verwijderd]

OpenXML wordt op de markt amper gebruikt, ODF is al jarenlang volop in gebruik, en kent ook ruime ondersteuning. Er is zelfs al een API voor alle gangbare programmeertalen voor ODF gereed die toegang tot de standaard sterk vereenvoudigt

[Bram S]

Beste MS/Raul,

Leuk dat er 160 applicaties zijn die iets kunnen met ooxml, maar dat zegt natuurlijk vrij weinig (en seriously, iphone bovenaan het lijstje? hoeveel mensen hebben zo'n ding in Nederland+Belgie? 2?), het gaat er natuurlijk - behalve in juridisch opzicht - om wat er gebruikt wordt. Als je dan ook vertaalprogjes meetelt wordt je lijstje al helemaal een beetje dubieus (met 18 vertaalprogjes en geen office pakket kan je net zoveel tekstverwerken als de gemiddelde demente zeehond)

de novell versie van OOo kan inderdaad overweg met ooxml, maar is ook een van de minst gebruikte versies (al is misschien ook deels te wijten aan de "besmetting" door MS)

Daarnaast zie ik nog steeds geen reden waarom we naast de standaard die we al hebben - ODF - nog een extra standaard moeten hebben. Zeker omdat MS zelf ook heeft aangegeven dat dit een prima standaard is (en voor de standardisering heeft gestemd). De compatabiliteit kan hier het probleem niet zijn, ooxml documenten zijn sowieso niet te openen in oudere MSO versies. Tenzij je een extra plugin hebt, maar er is ook prima een plugin te schrijven die oude MSO documenten converteert naar ODF (indien nodig kan de code hiervoor van OOo gebruikt worden, maar anders ook goed door MS zelf te schrijven, waarschijnlijk beter zelfs omdat jullie niet via reverse enginering alles moeten uitvogelen).

[Tijger]

Ok, en hoeveel daarvan zijn 100% compatible want dat bleek het struikelblok voor Nederland te zijn.

[Cameleon73]

Schokkend genoeg is er geen enkele implementatie die OpenXML voor 100% ondersteund (!)

[oliveroms]

en dat is goed, omdat ms zijn standaard toch weer is zal doordrukken.

back on topic, het is idd jammer dat er niet gewoon gestemt negatief met comments gestemt is, onder het mom van, er is reeds een standaard, maar ja, nederland heeft daar natuurlijk weer de ballen nie voor.

[Olaf van der Spek]

Ten eerste is er niks mis met meerdere standaarden zolang er niet sprake is van vendor-lockin en je gewoon vrij bent te kiezen welk formaat je wil gebruiken.

Natuurlijk is er wel iets mis mee. De gebruiker moet dan namelijk of applicaties gebruiken die beide formaten ondersteunen of per formaat een applicatie gebruiken en dat is echt niet handig.

Zie HD-DVD vs BD.

[Reactie gewijzigd door Olaf van der Spek op 24 juli 2024 21:39]

[Verwijderd]

Ik begrijp je niet, heb je uberhaubt gelezen wat ik schreef? Of was ik te onduidelijk?

Wat ik bedoel is dat in dit voorbeeld zowel MS Office als Open Office beide formaten zou moeten ondersteunen. Dan is er compleet geen sprake van vendor-lockin en kun je zelf kiezen welk formaat en welke office suite jij het liefst gebruikt.

Aangezien je toch de vergelijking met HD-DVD en Blu-Ray gebruikt is dus het principe wat ik bedoel een hybride-speler die beide formaten aankan. Je kunt dan zelf kiezen welk formaat je wil en als er genoeg keuze in apparaten is ook welk apparaat je ervoor wil gebruiken.

Ik weet, het is een beeld van een ideale wereld maar zou dit niet het doel moeten zijn waar we naartoe moeten werken. Niemand kan mij wijs maken dat dit niet zou werken als zakelijk model en dat er geen geld mee te verdienen valt.

Maar goed, je mag het altijd proberen.

[Mr_Light]

"een nee-stem die automatisch ja wordt als al het commentaar verwerkt is"

automatisch ja nadat iemand anders beslist of het verwerkt is, klinkt als een blanco cheque.

Volgens mij hebben we op software gebeid wel iets te zeggen, onze dienstverlening sector is behoorlijk groot, denk aan een aantal banken. Het grootste deel van het geld dat verdiend word aan software komt uit de financiële wereld. Daarnaast zijn wij ook rijk aan softwarebedrijven.

Er word misschien ge-"outsourced" naar Azië maar het strategisch niveau van die projecten zit in het westen.

Naast Amerika kan ik niet zo 1,2,3 kandidaten opnoemen die we voor ons zouden moeten dulden, misschien kan iemand anders dat op weg helpen.

[Verwijderd]

Ecma is al bezig met de commentaren aan het verwerken.
http://www.ecma-international.org/memento/TC45-M.htm

[psyBSD]

Approval with comments: goedgekeurd mits
Disapproval with comments: afgekeurd tenzij
Abstain: let niet op ons


Is er wel een manier om OpenXML af te keuren?!

[Maurits van Baerle]

Niet makkelijk

[psyBSD]

Als die man gelijk heeft dan zou Zwitserland voor OOXML stemmen als minder dan 75% van de leden tegen was. Dit vind ik erg moeilijk te geloven.

Maarja, ook in nederland schijnen we volgens dit artikel slechts drie keuzes gehad te hebben, 'ja', 'nee, maar toch eigenlijk ja', en 'wij zeggen niks'.

Nu kan het aan mij liggen, maar ergens vraag ik mij af of er geen corruptie in het spel is. Wat heeft het voor nut om te stemmen als alle stemmen maar een kant op worden geninterpreteerd? Je bent voor of het kan je niks schelen / mag er niks over zeggen...

Edit:
Of het moet overal goed mis gaan met de berichtgeving, want dit zou een grote rel kunnen worden als het waar is.

[Reactie gewijzigd door psyBSD op 24 juli 2024 21:39]

[Little Penguin]

Als de verwijzing naar ODF impliceerde dat OOXML enigszins overbodig is, dan is dat natuurlijk slecht nieuws voor Microsoft en partners, maar...

Ik kan me voorstellen dat het afzwakken van de verwijzing naar ODF dan ook weer een struikelblok voor Sun en ODF-partners is geworden.

Uiteindelijk zal men dus in een patstelling terechtgekomen zijn waarmen niet meer uit kon komen...

Overigens is het natuurlijk een beetje onzinnig om meerdere ISO standaarden te hebben voor office-toepassingen, voeg gewoon ODF en OOXML samen - waarbij je de beste punten uit beide standaarden probeert samen te voegen. Je zou bijvoorbeeld ODF uit kunnen breiden met de extra opties die OOXML nodig zou hebben t.o.v. legacy formaten, als die extra opties tenminste geen tegenstrijdigheden hebben cq opleveren...

[SirBlade]

Ik denk dat je dan beter, als straks alle onduidelijkheden uit de OOXML-specificaties zijn gehaald en deze ook is gecertificeerd, hier opties aan toevoegen voor ODF-compatibiliteit. ODF mag dan wel eerder zijn gecertificeerd maar OOXML is veel uitgebreider. En het is vast makkelijker 300 opties toe te voegen aan OOXML dan 3000 aan ODF.

[kidde]

ODF refereert aan veel andere - niet ISO - standaarden. OOXML is vooral uitgebreider omdat deze niet-ISO standaarden niet gebruikt zijn, maar in plaats daarvan Microsoft standaarden zijn gebruikt, en omdat sommige dingen meerdere keren voorkomen in de OOXML spec.

[Verwijderd]

Dat zeg je verkeerd. ODF gebruikt niet zozeer ISO standaarden maar met name W3C webstandaaarden en RFC's en vrijwel geen ISO standaarden.
Minder ISO standaarden nog dan OOXML.

Bijvoorbeeld OOXML is in staat om office formatting, revisie tags en voetnoten in math formules te gebruiken maar in ODF kan dat niet omdat ODF een externe w3c standaard MathML gebruikt die gemaakt is voor webpublicaties en bijvoorbeeld het concept van revisies bij houden niet kent.

[Little Penguin]

Dat zeg je verkeerd. ODF gebruikt niet zozeer ISO standaarden

Je leest verkeerd:
Kidde zegt dat ODF vooral referreerd aan andere standaarden, waarbij die standaarden niet van het ISO zijn.

Die standaarden zijn dan inderdaad van het W3C, die ook verantwoordelijk is voor de XML standaard zelf, veel van die standaarden zijn ontworpen met het extensibility idee in het achterhoofd. Helaas kun je dan niet per definitie zeggen van de diverse formaten die Microsoft ontwikkeld heeft en bij de OOXML hoop gegooid heeft...

Feit is echter wel dat men bij ODF probeert te kijken in hoeverre een toepassing reeds beschreven is en dan gebruikt maakt van die beschrijving, MS probeert bijna alles zelf te doen. Waarom kan men voor OOXML geen gebruik maken van SVG (Tiny) en moet met VML gebruiken?

Verder zijn er volgens mij voor XML formaten niet eens zoveel ISO standaarden en heeft het weinig zin om een formaat exact af te rekenen op het aantal referenties naar ISO standaarden. (waarbij het wel erg raar zou zijn dat een document van 6000 bladzijden minder verwijzingen zou hebben dan een document van plm 1000 pagina's)

[Verwijderd]

veel van die standaarden zijn ontworpen met het extensibility idee in het achterhoofd. Helaas kun je dan niet per definitie zeggen van de diverse formaten die Microsoft ontwikkeld heeft en bij de OOXML hoop gegooid heeft...

Vreemde opmerking . OMML (de math taal on Office open XML) bijvoorbeeld biedt meer functionaliteit dan mathML maar is ook nog een volledig compatible met MathML doordat je een simpele XSLT schema conversie kan doen van OMML naar MathML en omgekeerd. De XSLT schema files daarvoor zitten bijvoorbeeld los bij een Office 2007 installatie. Natuurlijk verlies je bij een conversie naar MathML wel eventuele extra functionaliteit in de OMML code. Dit is dus heel krachtig. Je hebt de Math features en de Office features ineen en kunt ze met een eenvoudige XSLT conversie omzetten naar een standaard web formaat waardoor je bijvoorbeeld heel simple MathML functies direct in OMML kan kopieren en omgekeerd. Hoge compatibiliteit maar wel gecombineerd met Office functioniliteit. Dit is veel beter dan het puur includen van MathML blobjes in je XML code zoals Opendocument doet.

Bovendien heeft Office Open XML veel betere extensibility features dan Opendocument en die slaan dus ook op de onderdelen van Office open XML zoals OMML. Je kunt dus de extensibility functionaliteit gedefineerd in ODF niet toepassen op de w3c web standaard onderdelen die in ODF hergebruikt worden.

Verder is bijvoorbeeld ook de Open Packaging Convention in Office Open XML veruit superieur aan de manier waarop Opendocument packages zijn opgebouwd.

Je hebt weliswaar veel meer definities in de spec maar je krijgt er ook een hoop functionaliteit voor terug die helemaal niet aanwezig is in ODF. Dat wordt echter ondergesneeuw in een barrage van kritiek van Microsoft haters, Office concurrenten en ODF fans. Soms terecht omdat er nog best wel aardig wat foutjes en slordigheden gevonden zijn. Maar vaak ook niet terecht zoals de suggestie dat ODF een veel beter formaat is en alles kan was OOXML ook kan. OOXML kan allerlei zaken die niet in ODF kunnen of heel complexe implementaties zouden opleveren.

[Maurits van Baerle]

Ik maak zelf geen converters maar mensen die dat wel doen hebben aangegeven dat er vijf concrete gevallen zijn waarin het voor hen lastig blijkt om OOXML data te vertalen naar ODF. Die vijf zaken zouden aangepakt kunnen worden in een samenvoeging van beide. 5 is wel ietsje minder dan 3000.

Er zijn overigens mensen die denken dat het sowieso onwaarschijnlijk is dat OOXML ooit een officiele standaard kan worden voor sommige overheden (vooral om juridische redenen) en dat zij (bijvoorbeeld de EU) uiteindelijk zullen aandringen op één standaard die waarschijnlijk een samenvoeging is van zowel ODF, UOF en OOXML.

[Reactie gewijzigd door Maurits van Baerle op 24 juli 2024 21:39]

[Verwijderd]

En nee, ODF is niet gelimiteerd ten opzicht van OOXML

Echt wel.
Maar afgezien van die discussie vraag ik me serieus af of ODF voorstanders een ODF formaat willen waarop Microsoft enorme propriety extensies heeft geschreven.
Extensies die je overigens niet hoeft te documenteren en waarop je ook geen patentrechten hoeft af te staan !!!

Daar zit toch niemand op te wachten !!!

[kidde]

Inderdaad, mensen zitten niet te wachten op propriety extenties in ODF. Mensen zitten namelijk in het algemeen niet te wachten op propriety extenties, en daarom zijn deze in den beginne niet geimplementeerd in ODF. Pas toen bleek dat ze _wel_ in OOXML zaten, heeft men ze toegelaten in ODF om compabiliteit te kunnen waarborgen. Zonder OOXML's propriety extenties hadden genoemde extenties dus niet in ODF gezeten.

[Little Penguin]

Welke limitaties heeft ODF+verwijzingen dan t.o.v. OOXML? Ik weet dat in ODF niet goed gespecificeer is hoe je in een spreadsheet formules vast moet leggen, daar moet nog aan gewerkt worden - en daar is men ook mee bezig.

Maar voor het overige?

[Verwijderd]

Er zijn nog talloze andere zaken
Ik heb er kort een paar genoemd hier eerdr in deze thread:
http://tweakers.net/react...=Posting&ParentID=2151221
Het valt echter buiten het kader van een reactie om een uitgebreide vergelijking te maken.

[Freeaqingme]

Dat is hypocriet imo.

Als iedereen zo denkt, dan is toch zo'n beetje het hele idee van stemmen overbodig.

Als iedereen bij de verkiezingen in Nederland zich onthoud van een stem, immers, 1 persoon heeft toch niets te zeggen, dan ben je nog nergens....

[tuXzero]

Waarom hebben we ook al weer meerdere standaarden nodig?

Ik denk dat ze niet nodig zijn, waarom bestaan er anders standaarden organisaties. Puur dat Microsoft zo krachtig is wordt er zo bende van gemaakt. Als ik hompti... dompti... met mijn dik pak papier (OOXML) kom dan wordt het al afgekeurd omdat er twijfel is en omdat er al een goed standaard bestaat.

En nee, ODF is niet gelimiteerd ten opzicht van OOXML Microsoft weigert simpelweg hun office pakket compatibel met ODF te maken. ODF is namelijk uitbreidbaar, dus ze kunnen toevoegen wat ze aan functionaliteit missen. Maar ze moeten het dan wel volgens de ODF way die toevoegingen bekent maken. En dat willen ze niet.

Als je ISO niet kan leveren, hou dan die achterbakse trucjes bij je!