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

Door , , 85 reacties

De International Organization for Standardization heeft de balans opgemaakt: ooxml zal vooralsnog geen officiële ISO-standaard worden. De mogelijkheid dat dit in februari 2008, na het doornemen van de commentaren, alsnog gebeurt, blijft.

ISO logoDe standaardencomités hebben van april dit jaar tot en met 2 september de tijd gehad om te stemmen over het voorstel om van Office Open XML een ISO-standaard te maken. Voor een goedkeuring moet minstens tweederde van de nationale comités die participeren in de ISO/IEC JTC 1-werkgroep vóór stemmen en mag niet meer dan een kwart van alle stemmen negatief zijn.

Aan geen van deze twee criteria is voldaan. In totaal was 53 procent van de stemmen van de in ISO/IEC JTC 1 participerende stemmers positief. Van alle stemmende landen bracht 26 procent negatief advies uit.

De commentaren die de verschillende landen samen met hun stem naar de ISO hebben gestuurd, zullen tijdens een bijeenkomst van een week in februari 2008 besproken worden. Tijdens die vergadering zal gezocht worden naar consensus over eventueel door te voeren wijzigingen in de ooxml-specificatie.

Microsoft blauw logoAls de wijzigingen in de specificatie zijn doorgevoerd, krijgen de tegenstemmers de mogelijkheid om hun stem te veranderen. Als dan wel voldaan wordt aan de eisen die hierboven reeds genoemd werden, zal ooxml alsnog een officiële ISO-standaard worden. Mocht ook dan geen meerderheid voor zijn, wordt het versnelde traject voor standaardisering afgebroken en moet het normale traject bewandeld worden.

Microsoft interpreteert de stemresultaten positief: het bedrijf benadrukt dat 74 procent van alle stemmers een ISO-certificaat voor de ooxml-specificatie wel ziet zitten. Daarnaast schrijft het Redmondse bedrijf in zijn persbericht dat het blij is met de gegeven commentaren, omdat die de standaard alleen maar beter kunnen maken. Verder verwijst Microsoft naar de stemming over de ISO-ratificatie van het Open Document Format, dat vergelijkbare cijfers liet zien na de eerste stemronde. Al met al ziet het bedrijf de toekomst voor ooxml dan ook zonnig in.

Moderatie-faq Wijzig weergave

Reacties (85)

Verder verwijst Microsoft naar de stemming over de ISO-ratificatie van het Open Document Format, dat vergelijkbare cijfers liet zien na de eerste stemronde.
Dat klopt niet. OpenDocument heeft de procedure in één keer doorlopen met de vereiste meerderheid. Er is geen enkele tegenstem (No, No with comments) geweest, alleen 'Approval' (18), 'Approval with comments' (5) en 'abstention' (2).

http://www.jtc1sc34.org/repository/0728revc.htm
Inderdaad een kwestie van interpretatie:

-Zo is Microsoft er ook trots op dat er 10.000 commentaren op haar standaard binnenkwamen (wel overlappende natuurlijk), wat al aangeeft dat de standaard dus bij lange na niet over de kwaliteit beschikte om het tot ISO-standaard te schoppen. Die 10.000 comments moeten in feb 08 binnen één week besproken worden (ben maar eens trots op zo'n standaard als die het red!)

-Microsoft is blij dat 74% van de stemmen positief waren; maar vergeet erbij te vermelden dat het met name haar eigen Gold-Members waren die speciaal van nationale standaardenorganisaties lid werden vlak voor de stemming over dit onderwerp, en daar slechts en slechts alleen zaten om vóór DIS29500 (OOXML) te stemmen, nog afgezien van meer dan tien nieuwe P-members in de laatste maand. Microsoft vindt het kennelijk niet erg dat de geloofwaardigheid van ISO voorgoed is aangetast door dit gedrag.

-Kennelijk vindt Microsoft het ook niet zo erg dat ze tegen internationale standardisatie-organen heeft gelogen over het feit dat 'Ja, maar onder de voorwaarde dat' niet betekend dat aan deze voorwaarden verplicht moet worden voldaan (alleen een 'Nee, tenzij' zorgt daarvoor).
Waar staat op die website dat dat de eerste keer is dat er over ODF is gestemd, ik vind het vrij onduidelijk. Het lijkt me sterk dat Microsoft zoiets gewoon verzint.
De eerste ronde was op 1 mei 2005. Er was van tevoren een tweede ronde ingepland voor augustus 2005 (een zogeheten Ballot Resolution Meeting) maar die bleek na de eerste ronde niet nodig omdat er geen 'No with comments' stemmen waren in de eerste ronde.

The ISO Process and Schedule for ODF Comment Reconciliation
Ik ben erg benieuwd hoe er nu omgegaan zal worden met de commentaren die aangeven dat de ECMA OOXML standaard een duplicaat is van de ODF-standaard. Als men deze commentaren correct wil verwerken zal er toch overleg moeten komen tussen het ECMA en OASIS...

Waarbij het natuurlijk het mooist is als er één standaard komt die zowel zo veel mogelijk de ontwerpprincipes van OOXML (backward compatibiliteit, maar dan alleen waar mogelijk en er geen conflicten ontstaan) en ODF (het maken van een applicatie-neutrale documenten standaard) samengevoegd worden.

Verder moet deze nieuwe standaard de ontwerp principes van XML zo goed mogelijk volgen, dus een voor mensen enigszins leesbare XML opleveren. Waarbij die XML dan geen interne conflicten mag hebben - bijvoorbeeld: zodat er voor documenten niet een andere manier van het samenstellen van de namen is dan bij de spreadsheets...
-
Microsoft interpreteert de stemresultaten positief: het bedrijf benadrukt dat 74 procent van alle stemmers een ISO-certificaat voor de ooxml-specificatie wel ziet zitten.
Lekkere rekenaars daar in Redmond: 53% was voor en 26% tegen en dus is volgens Microsoft 74% voor.

Ik denk dat je die overgebleven twintig procent weer eerlijk zou moeten verdelen tussen die 53% en 26% (53+26=79) als je dan 53/79 doet dan krijg je een totaal van 67% voor en 33% tegen, er van uitgaande dat de voor en tegenstanders eerlijk verdeelt zijn bij de 'onthouding' stemmen...

[Reactie gewijzigd door Little Penguin op 4 september 2007 22:12]

Tja... zou prettig zijn als ODF en OOXML samengevoegd werden tot één daadwerkelijk goed systeem.

Maar daarvoor is er teveel politiek gekonkel. Gelijk vanaf het begin af aan zat er een duidelijke anti-MS kant aan ODF. Logischerwijze leidde dat tot een OOXML antwoord.

Ik denk dat het veel te laat is om dat weer recht te zetten. Daarvoor is er nu te veel gebeurt.
Dat kan niet omdat ODF onbruikbaar is in moderne tekstverwerking, het is nog lang niet af.
Er zijn 51 voorstemmen en 18 tegenstemmen
Onthoudingen tellen niet mee in ISO stemmingen

51/69= 0,7391

74% is dus heel correct !!!
Neither of these criteria were achieved, with 53 % of votes cast by national bodies participating in ISO/IEC JTC 1 being positive and 26 % of national votes cast being negative.
Bron: http://www.iso.org/iso/pressrelease.htm?refid=Ref1070
Als onthoudingen niet tellen, dan moet de overgebleven 21% blanco gestemd hebben blijkbaar. Anders kan het ISO niet tot bovenstaande conclusie komen.

Uiteindelijk blijft het echter zo dat slechts 53% ook echt voor was - nog steeds op basis van het persbericht dat door het ISO de wereld ingeholpen is.
Creatief rekenen heet dat.
Lekkere rekenaars daar in Redmond: 53% was voor en 26% tegen en dus is volgens Microsoft 74% voor.
Het zit zo:
53% van de 'belangrijke' landen voor, sommige onder voorwaarden (comments), maar Microsoft loog erover dat die voorwaarden harde eisen waren (wat volgens ISO niet zo was)
26% van de 'belangrijke' landen tegen

74% van alle landen voor. Omdat dat meer 'lijkt' dan de 53% van de belangrijke landen vóór, gebruik je dat getal als Microsoft (duh!).

De vraag is: Wanneer is een land belangrijk? Vóór augustus dit jaar was dat als een land veel deelnam aan standaardencommittees. In augustus dit jaar waren er echter in een keer meer dan negen nieuwe P-members (belangrijke landen), zoals Libanon, Cyprus, Malta, Ivoorkust, Costa Rica, Turkije, Uruguay, Venezuela en Pakistan (voorstemmers), Trinidad en Tobago (onthouding), en Equador (tegen). Deze landen zijn, het kan haast niet anders, belangrijke landen geworden (dat kunnen ze zelf aanvragen) om zwaarder te wegen om mee te kunnen stemmen speciaal voor OOXML.

[Reactie gewijzigd door kidde op 5 september 2007 00:37]

Als de wijzigingen in de specificatie zijn doorgevoerd, krijgen de tegenstemmers de mogelijkheid om hun stem te veranderen.

Over principes gesproken... ;)
Hoezo principes? Als je deelneemt in de International Standards Organisation lijkt het me nogal tegenstrijdig om principieel tegen wat voor standaard dan ook te zijn. Andere bezwaren (technisch, juridisch, etc.) kunnen opgelost worden, waarna het me doodnormaal lijkt dat landen hun mening kunnen herzien. Bedenk ook dat de ISO standaarden wel kan vastleggen, maar dat niet betekent dat ook maar iemand het hoeft te gaan gebruiken. De strijd tussen OOXML en ODF zal dus zeker niet door de ISO beslist worden.

[Reactie gewijzigd door Wouter Tinus op 4 september 2007 23:23]

De strijd tussen OOXML en ODF zal dus zeker niet door de ISO beslist worden.
Ik ben huiverig dat zodra ooxml een iso standaard wordt de strijd op de zelfde manier als de Internet Explorer / Netscape strijd opgelost gaat worden. C.q. de ooxml output van Microsoft Office wordt niet helemaal correct weergegeven op een product anders dan Microsoft Office. Waardoor (bijna) iedereen voor Microsoft Office in combinatie met ooxml gaat kiezen en een ander product nooit een reële keuze zal zijn.

Ik hoop dat ik het mis heb.
Ik ben huiverig dat zodra ooxml een iso standaard wordt de strijd op de zelfde manier als de Internet Explorer / Netscape strijd opgelost gaat worden.
De strijd "Internet Explorer vs Netscape" werd even iets anders uitgevochten: leveranciers van OEM PC's kregen gewoon geen licenties meer van Microsoft als ze Netscape op de PC's meeleverden, of moesten hogere prijzen betalen.
Daar is een mooi boek over geschreven, Microsoft heeft er later ook nog een knappe schadevergoeding voor betaald aan Mozilla...

Maar je angst dat Microsoft hun eigen standaard erdoor gaat drukken door OOXML net even niet helemaal compatibel te maken met concurrenten van Office: daar ben ik ook bang voor!
Nee, hoor dat zie je goed. De huidige MS Office 2007 gebruikt ook al een uitbreiding op OOXML. Dus dat komt wel goed:
* Standaard omarmen, en uitnodigen tot onafhankelijke implementaties.
* Standaard uitbreiden, 'helaas' onvereenigbaar met de onafhankelijke implementaties.
* Door het marktoverwicht de 'de facto' standaard zijn. Helaas zonder concurrerende implementaties.
Hmpf... dat is wel een enorm slecht voorbeeld.
De Internet Explorer / Netscape strijd is gewonnen door IE, omdat het simpelweg de betere browser was. Netscape 4.x was een verschrikkelijk ding. Men heeft het nu wel altijd over gebrekkige CSS implementatie van IE, maar toentertijd was IE voorloper op dat gebied, en liep Netscape mijlenver achter.

CCS op Netscape 4.x is het meest verschrikkelijke dat er bestaat. Floats waren volkomen onbruikbaar. Dan hebben we het niet over kleine afwijkingen zoals momenteel met IE, maar over situaties dat tekst volkomen over plaatjes heen liep, waardoor het totaal onleesbaar werd. Men is niet voor niets van scratch begonnen met de renderer van Netscape 6. Dat oude 4.x ding was volkomen onbruikbaar voor de toekomst.

Het enige 'gemene' aan IE was dat het gratis was, en Netscape eigenlijk niet. (Tenzij je student was)
Sry, hoor maar wie gebruikte floats in de tijd van netscape 4, het was tables alom, pas de laatste paar jaar worden floats icm div layouts veel gebruikt.
Ze hebben er wel flinke invloed op omdat overheden regels gingen opstellen die open standaards verplichtte binnen de eigen organisatie (en naar de burger toe?).
Dat was de primaire reden dat Microsoft in een bliksemflits met ooxml kwam.
Eigenlijk is het raar geformuleerd; iemand die stemt 'Nee, tenzij' stemt eigenlijk voor, onder bepaalde voorwaarden. Het is dus een voorwaardelijke ja-stem. Echter, bij een voorwaardelijke 'Ja, onder de voorwaarde dat' stem hoeft niet per se op deze voorwaarden ingegaan te worden in de komende overlegronde, wegens ISO regels (is raar, maar is nu eenmaal zo). Daarom hebben een aantal landen die bedoelden 'Ja, onder de voorwaarden dat' nu: "Nee, tenzij" gestemd.

Als de wijzigingen in de spec zijn doorgevoerd, verandert de stem ("ja, onder de voorwaarde dat") niet. Echter, de specificatie zelf is veranderd om aan die voorwaarden te voldoen, en dus veranderd de 'uitkomst' van de stem. Maar in principe (over principes gesproken) verandert de stem dus niet.
Hoe meer ik over de regels van de ISO lees, hoe meer ik me afvraag waarom we uberhaupt naar die lui luisteren. Het soort vage constructies dat zij gebruiken, zie je zelfs in de Haagse politiek niet terug.
Cuba is voor??? Microsoft staat niet eens toe dat hun producten daar verkocht worden... Hetzelfde voor Syrie.
Het is voor deze landen belandrijk dat ze de bestanden van office wel kunnen openen met andere programma's die wel zijn toegestaan. Dat gaat veel makkelijker als je een openstandaard hebt dan een gesloten.
En, vergeet niet dat dit handels-embargo wordt opgelegd door de Amerikaanse overheid. Het is voor hun ook onmogelijk om te exporteren naar de VS (van CUBA weet ik het zeker, van Syrie niet), een beetje goodwill kweken kan dan voor hun dus echt geen kwaad.

En een Amerikaans bedrijf met een Internationaal monopolie helpen met het behouden van die positie is echt iets wat het goed doet bij de regering in de VS.
Hopelijk komt van uitstel afstel.

De wereld heeft momenteel geen twee "open" standaarden nodig. Zeker als de voorgestelde standaard minder open is.

Zeker de ooxml niets positiefs toevoegd. Vaak wordt er gezegd backwards compatibel, dat IMO onzin. Al je een doc file al in een ooxml file zipped kun je net zo goed helemaal omzetten naar odf. Zoiets kan volledig geautomatiseerd worden.
Er is niets mis met meerdere standaarden. Ik kan metrische boutjes en schroefjes kopen, of amerikaanse inch-maten. Twee standaarden die goed beschreven zijn. Door die goede beschrijving kan ik van beide soorten boutjes en moertjes bij willekeurig welke fabriek laten maken, de standaard zorgt dat ze passen.

Het grote probleem met ooxml is dat de standaard niet volledig is. Om de metafoor van de boutjes nog even terug te halen staat er in de ooxml zoiets als "schroefdraad conform de naaimachine op zolder", zonder toegang te bieden tot die naaimachine. Daardoor kan jij wel passende boutjes aan de hand van de standaard (en jouw naaimachine) maken, maar niemand anders. En daarmee is de waarde van ooxml dus nul.
Als er 1 standaard is die niet volledig is is het wel Opendocument.
Office Open XML is natuurlijk een stuk vollediger dan OpenDcoument dat zelfs geen spreadsheet formulas bevat
Office Open XML is natuurlijk een stuk vollediger
Niet waar; OOXML documentatie zit vol gaten (al zijn ze verstopt).

-in OOXML kunnen VML genest binnen OLE-gedeelteen (gesloten formaat) terechtkomen na het encrypteren van bestanden, dit is allemaal helemaal niet gespecificeerd,

-VML gedeelten worden 'ingepakt' in XML, maar VML is geen onderdeel van de documentatie,

-de tientallen "locale's" die voor bijvoorbeeld datums gebruikt kunnen worden zijn niet gespecificeerd, data worden in OOXML tevens weergegeven als integere getallen (het aantal dagen na een bepaalde datum)- en de lezer moet maar raden dat het om datums gaat.

-OOXML verwijst naar twee nieuwe, gesloten, BIFF-standaarden (de oude gesloten office-formaten), BIFF 11+ en het geheel nieuwe, nog nergens gespecificeerde BIFF12.

-De plaatsen waar bestanden in het ingepakte OOXML bestand staan zijn nooit zeker, en het hele zootje is niet goed gespecificeerd,

-MS Excel zorgt ervoor dat oude optimalisatie-patronen binnen OOXML terechtkomen, maar niet gespecificeerd in OOXML.

-Afrondingsfouten (volgens IEEE) komen in OOXML terecht zoals MS Excel dat doet, niet gespecificeerd in OOXML.

Bron

-Talloze legacy tags worden niet gespecificeerd (wat ook niet kan omdat dat de EULA van de desbetreffende software zou breken) Bron: Algemeen bekend op Tweakers

-OOXML gebruikt gesloten encryptie-algoritmen bron

Overigens: de spreadsheets-formules van OOXML zijn misschien gespecificeerd, maar deugen voor geen meter. Wie ze in de OOXML-bestanden gaat lopen bewerken met een texteditor stuit op 'catastrophic failure' boodschappen binnen MS Excel (zie eerste bron).

[Reactie gewijzigd door kidde op 5 september 2007 01:20]

@Kiddie: Ook ODF kan streams en objecten bevatten welke niet in de ODF specificatie zijn beschreven. Dat noemen we embedded content. Ook in OpenOffice kun je bijv. een Visio diagram opnemen.

Alle locales die Microsoft gebruikt zijn al beschreven door de ISO (Basis vormen de iso standaarden 639 en 3166). ISO heeft per land (locale zoals nl-NL, nl-BE, etc) beschreven wat de presentatie schrijfwijze van dat land voor datums, munteenheden, getallen, etc. Dat hoeft microsoft niet nogmaals te beschreven.

Hoewel VML (Vector Markup Language) geen erkende standaard is (tegenstem van o.a. Adobe en sun) is de specificatie wel in 1998(!) bij het W3C (link) neergelegd. Iedereen kan dus die specificatie implementeren. CSS is ook een specificatie van microsoft welke tevens na afwijzing als standaard bij het W3C is neergelegd.

Omdat ooxml bij ecma is neergelegd, betekend dat iedereen alle gerelateerde technologien en patenten royalty free mag implementeren. Dat is namelijk een harde eis voor elke ecma specificatie.

Een ooxml bestand is in eerste instantie een zip bestand met daarin meerdere xml documenten. Dit is beschreven in de OPC specificatie (link).

Ook de gebruikte encryptie algoritmes zijn beschreven in OPC. Misschien als je zelf wat onderzoek had gedaan in plaats van klakkeloos overnemen wat andere hebben geschreven dan had je dit ook geweten.

Overigens wordt de plaats waar iets staat wordt bepaald via Xlink. Inderdaad niet beschreven in de ooxml documentatie, maar wel bij het W3C. Misschien had je de sectie 'references'. Neem anders eens een kijkje op http://openxmldeveloper.org. Die website heeft Microsoft speciaal in het leven geroepen voor developers.

OpenDocument zal net als OPC bestaan uit een serie van (ISO) standaarden.
ooxml worden de de OPC specificaties (serie van meerdere open standaarden. De helft van de ODF specificatie is nog in ontwikkeling (ik verwijs naar de OASIS werkgroepen Accesbility, Formula en en MetaData.

Alleen OpenDocument 1.0 is door het ISO erkent als standaard. Voor OpenDocument 1.1 (geaccepteerd door oasis in februari) moet het hele ISO traject weer worden doorlopen. Waar ecma de mogelijkheid bestaat om meerdere versies van een specificatie te beschreven (denk aan javascript (ecma-262), C# (ecma 334)), bestaat deze mogelijkheid bij ISO niet. Dat heeft te maken dat ISO ook een zogenaamde conformatie organistatie is. Als bedrijf X claimt ISO te voldoen aan standaard 26300 (ODF), kan het niet zomaar gebeuren dat de specificatie veranderd.

Wat mij betreft worden gewoon beide documenten tot standaard verheven.

Waar Microsoft een van de drijvende krachten achter xhtml was, kwamen kort geleden Mozilla, Opera en Apple met de html 5 specificatie op de proppen als alternatief voor xhtml 2.

Alle bedrijven (niet alleen Microsoft) hebben er een handje van hun eigen specificaties tot een standaard te laten uitroepen. Het beste voor de wereld is dan om die bedrijven hun specificaties zo volledig mogelijk te laten beschrijven zodat iedereen vrij is om daarvoor een implementatie te schrijven.
Hoewel VML (Vector Markup Language) geen erkende standaard is (tegenstem van o.a. Adobe en sun) is de specificatie wel in 1998(!) bij het W3C neergelegd. Iedereen kan dus die specificatie implementeren.
Alleen is er inmiddels een beter alternatief voor VML beschikaar en dat is SVG. Die laatste wordt door veel meer tools ondersteunt en is dus een beter alternatief. Natuurlijk gebruiker MS liever haar eigen standaard omdat ze voor de implementatie van SVG zelf veel werk moeten gaan verzetten.
CSS is ook een specificatie van microsoft welke tevens na afwijzing als standaard bij het W3C is neergelegd.
Laatste keer dat ik gekeken heb was CSS een W3C specificatie, waarbij Microsoft de laatste stabiele versie nauwelijks geimplementeerd heeft (CSS2) en van CSS3 bijna niets geimplementeerd heeft...
Waar Microsoft een van de drijvende krachten achter xhtml was, kwamen kort geleden Mozilla, Opera en Apple met de html 5 specificatie op de proppen als alternatief voor xhtml 2.
Microsoft een van de drijvende krachten achter XHTML? Laat me niet lachen, HTML5 is ontstaan vanwege het feit dat MS erg traag/laks is met het implementeren van externe standaarden zoals XHTML.

Als Microsoft gewoon in IE6.5 (die dan al in 2003 uitgebracht had moeten zijn overigens) XHTML+CSS2+JS1.5 ondersteuning had dan zou HTML5 nooit ontstaan zijn. HTML5 is een antwoord op de laksheid van MS, zodat browserfabrikanten door kunnen gaan met het ontwikkelen van HTML met een compatibiliteits laag voor IE...
Alle bedrijven (niet alleen Microsoft) hebben er een handje van hun eigen specificaties tot een standaard te laten uitroepen. Het beste voor de wereld is dan om die bedrijven hun specificaties zo volledig mogelijk te laten beschrijven zodat iedereen vrij is om daarvoor een implementatie te schrijven.
Het beste voor de wereld dat is dat de standaarden door externe experts (in overleg met de betreffende bedrijven dat wel) gemaakt worden, waarbij de bedrijven deze standaarden volledig gaan implementeren.

Op die manier kan iedereen de standaard volledig implementeren en heeft niet een bedrijf een voordeel t.o.v. het andere...
SVG bestaat al 6 jaar als een W3C recommendation en er is nog steed geen tool die volledig SVG ondersteunt. SVG is helemaal niet per se een beter alternatief.
Verder is ODF SVG geen volledige SVG maar een deelimplementatie aangevuld met afwijkende 3D ondersteuning die in SVG niet voorkomt.
Als je in OpenOffice een SVG documentje/elementje plakt dan wordt het behandeld als een extern file en vormt dan geen onderdeel van de ODF code. Om het te bewerken heb je dan op je computer een tool nodig om SVG files te bewerken. Als je in MS Office een SVG documentje plakt dan probeert MS Office dat om te zetten naar VML en als dat kan in de OOXML code te integreren en kun je dat dan ook eventueel bewerken met in in Office aanwezige grafische tooling.
Je heb te veel de tekst van Stephane Rodriguez gelezen.
Echter zijn commentaren zijn gewoon puur gericht op de implementatie van OOXML in MS Office 2007. Dat is gewoon een niet optimale implementatie (en dat valt ook te verwachten voor een implementatie die vrijwel tegelijk met het de standaard ontwikkeling is gebouwd.

* VML is gewoon gedocumenteerd in OOXML. 600 pagina's maar liefst. Wat niet is gedocumenteerd is hoe een graphics object er exact uit ziet. Dat is echter ook niet in alternative graphische standaarden als SVG beschreven.
* OLE is technology die gewoon in OpenDocument wordt ondersteunt. Als je in OOXML OLE gebruikt kan je dat gewoon ook op vrijwel identieke in ODF implementeren.
* OOXML verwijst helemaal niet naar BIFF formaat maar MS Office gebruikt dat nog wel embedded in OOXML files. Dat is echter geen onderdeel van OOXML maar een extern formaat. Je kunt ook wel BIFF gecodeerd files gaan toevoegen aan een ODF file (zoals de Da vinci converter doet) toevoegen maar dat heeft ook geen betrekking op het formaat.
* Afronding is een implementatie issue. De document standaard beschrijft dat niet. Als Excel daarin afwijkt is dat een keuze van Excel maar dat wordt niet door OOXML bepaald.
* De plaats waar documenten in een OOXML file staan is duidelijk in de packaging beschreven. Het is juist in ODF waar dat problemeen oplevert omdat van embedded files niet duidelijk is waar ze worden aangeroepen. Als je dus een file wilt verplaatsen of hernoemen in een ODF package dan moet je elk onderdeel van het document doorzoeken om te controleren of er een link naar dat file ergens tussen staat. Bij OOXML hooef je alleen in een relatief kleine hoeveelheid relationship files te kijken. alleen een verstokte tegenstander kan de waardeloze package indeling van ODF beter vinden dan die van ODF.
* Je kunt een spreadsheet best met een tekst editor aanpassen maar handig is het niet. Je moet dan als er een optionele calcchain.xml aanwezig is die eventueel ook bijhouden of weggooien. Vergelijke afhankelijkheden komen niet alleen in OOXML voor maar zitten ook in ODF. Ook daar zijn er optionele lijstonderdelen (change tracking list) die stuk kunnen gaan als ze niet tegelijk met wijzigingen in de spreadsheet worden bijgehouden. Dat excel een failure geeft op een corrupte calcchain in een OOXML file is implementatie van Excel. Een betere implementatie kunt ook de corrupte calcchain weggooien en rebuilden. In ieder geval heeft ook dat geen betrekking op OOXML maar op de manier hoe je dat implementeert.
Echter zijn commentaren zijn gewoon puur gericht op de implementatie van OOXML in MS Office 2007.
Klopt als een bus. En daar zit precies het probleem: Hiermee geeft Microsoft aan dat het geen donder om ECMA376 geeft (ze gebruiken het zelf niet eens als standaard opslagformaat), en dat ze zelf niet eens ECMA376 fatsoenlijk kunnen, of willen implementeren. In het eerste geval zijn ze incompetent (wat ik niet geloof), in het tweede geval willen ze gewoon geen open standaard gebruiken.

Vergeet niet dat het Microsoft Office zal zijn die de meeste OOXML bestanden zal gaan produceren, en als een 3de partij applicatie deze niet goed kan lezen vanwege wan-implementatie van Microsoft, zullen klanten denken dat de software van de 3de partij niet deugt, waar Microsoft op uit is. De echte OOXML standaard zal defacto Microsof Office XML zijn, en niet ECMA376/ISO29500 XML. Wat er gebeurt als Microsoft ECMA376 zelf niet gebruikt, is dat straks ECMA376 bestanden compatibel zijn met OOXML-ondersteunende software van 3e partijen, maar dat Microsoft OOXML documenten niet door 3de partij software gelezen kunnen worden.
Je kunt een spreadsheet best met een tekst editor aanpassen maar handig is het niet.
Ehhm, pardon? Dat is toch precies het doel van interoperabiliteit; dat je geen MS Excel nodig hebt om de spreadsheets aan te passen? Grapjas...
Je heb te veel de tekst van Stephane Rodriguez gelezen.
Beter dat dan de propaganda van Platform Strategy a.k.a. afdeling Evangelism van Microsoft reproduceren, hoewel je voor dat laaste meer geld en soms een laptop met kerstmis krijgt :) (Ik wens hem je nog steeds, voor je vele inzichtvolle vrijwillige werk voor een NPOV)
dat valt ook te verwachten voor een implementatie die vrijwel tegelijk met het de standaard ontwikkeling is gebouwd.
Elders zegt hAl op de opmerking dat OOXML nieuw , ongetest, onbetrouwbaar en onstabiel is, dat er al diverse jaren binnen Microsoft aan OOXML gewerkt wordt. Dus welke van de twee is het nu?

Overigens leuk om te zien hoe OOXML advocaten de fouten in ODF aanvoeren om anderen duidelijk te maken dat het niet erg is dat OOXML zuigt.

@Niemand_anders;
Het beste voor de wereld is dan om die bedrijven hun specificaties zo volledig mogelijk te laten beschrijven zodat iedereen vrij is om daarvoor een implementatie te schrijven.
Je verwart het belang van die bedrijven met het belang van de wereld: Het standaardiseren van standaarden die maar binnen 1 bedrijf worden gebruikt is alleen goed voor dat betreffende bedrijf zelf. Maar verschillende bedrijfsspecifieke standaarden voor hetzelfde doel kost het bedrijfsleven en de industrie miljarden, zoals ik elders uitgebreid betoogd heb. Die stelling is tot stand gekomen vanwege m'n dagelijkse ervaring met 'ouderwetse' DIN/ISO normen uit de metaalindustrie (en nog een hoop ervaring met het converteren van metrische/imperiale eenheden), waar de normen al redelijk 'geoptimaliseerd' zijn. Echter, in een onvolwassen sector als de ICT industrie kunnen bedrijven (vooralsnog) met meerdere standaarden voor hetzelfde doel ("de klant zoekt het maar uit met al die verschillende standaarden, dan doen wij ondertussen werk dat al door vele andere bedrijven is gedaan") weg komen.
als je zelf wat onderzoek had gedaan in plaats van klakkeloos overnemen wat andere hebben geschreven
Sorry, maar ik ben pas op pagina 20 van de OOXML spec (das dan weer het nadeel van wél een sociaal leven hebben), nog 5990+ te gaan, dus voorlopig ben ik afhankelijk van wat anderen schrijven.
Alle locales die Microsoft gebruikt zijn al beschreven door de ISO (Basis vormen de iso standaarden 639 en 3166
Leuk om het probleem heen gepraat. ISO beschijft echter niet de namen voor Bold, Italic en Underlined en lettertypes in de 80+ verschillende talen die OOXML gebruikt.

[Reactie gewijzigd door kidde op 5 september 2007 18:07]

Je kunt wel jaren met iets bezig zijn maar dan nog niet in 1 keer een optimale ondersteuning kunnen bieden.
Microsoft is natuurlijk al jaren bezig met XML gebaseerde formaten dwaar OOXML een duidelijke afgeleide is. Het is echter geen sinecure om een complete complexe Office suite eventjes om te bouwen zodat alle onderdelen tegelijk met OOXML kunnen werken. Wat bijvoorbeeld Stephane doet met het creeren van correcupte calcchains in een OOXML file is natuurlijk iets wat je met binare bestanden niet deed. Dat MS Office daar nog geen voorziening voor heeft gebouwd is dus nog niet zo vreemd.

Dat het niet evident is om even een Office suite aan te passen aan een nieuwe document standaard bewijst ook OpeNOffice die nog steeds de al twee jaar oude ODF spec niet volledig hebben geimplementeerd en die was ook gebaseerd op een door Sun/OOo gedoneerd voorlopend formaat.
Office Open XML is natuurlijk een stuk vollediger dan OpenDcoument dat zelfs geen spreadsheet formulas bevat
volgens wikipedia:
The OpenDocument ISO specification does not contain a defined formula language. This means that ISO conforming files do not have to be compatible.[24] OASIS is working on creating a standard formula language (OpenFormula) for OpenDocument v1.2 due later in 2007.
Ze hebben ODF wel heel snel als standaard naar voren geschoven, deels vanuit marketing oogpunt natuurlijk. Daardoor is de specificatie nog niet helemaal compleet. (het grote doel was ODT, voor tekstverwerkers, spreadsheets waren daarbij een ondergeschoven kindje.

In werkelijkheid zal iedere ODF compliant applicatie gewoon de formula van open/star office snappen. Tot de 1.2 spec er is en goedgekeurd is door ISO. Ik vermoed dat die weinig zal afwijken van de formula language zoals die nu al actief is in OpenOffice, en aangezien dat volledig OpenSource is kan iedereen die specificatie bekijken. Iets wat je bij Office van Microsoft wel kunt vergeten natuurlijk. Microsoft heeft in het verleden nogal gebrekkige documentatie opgeleverd, en half-bakken specificaties verzonnen. Ik loop er in mijn werk nog regelmatig tegenaan dat Microsoft soms erg onfatsoenlijk werk aflevert.

En voor iemand me van fanboy gedrag gaat beschuldigen: ik werk dagelijks met zowel Opensource (FreeBSD en Linux) als Closed Source (Windows/Microsoft) oplossingen. En hoewel ik een groot voorstander ben van opensource, heb ik altijd al gezegt dat de toekomst ligt in het combineren van die twee. ja, ik ben kritisch jegens MS, maar dat komt vooral door jarenlange profesionele ervaring met hun software.
Waarbij het grootste gedeelte van de OOXML spreadsheet documentatie een copy-paste is van de Excel help. Is dat echt voldoende voor een 3rd party om een correcte implementatie te maken?

Verder wordt er hard gewerkt aan een open specificatie t.b.v. spreadsheet formules - in samenwerken met academici. Deze gaat door het leven als OpenFormula een zal t.z.t. een onderdeel worden van OpenDocument...
sja, ms office openxml bevat wel de spreadsheet formules, alleen zijn ze niet allemaal even correct (zie o.a. http://www.robweir.com/blog/2007/07/formula-for-failure.html)

Momenteel wordt er bij ECMA een standaard voor spreadsheet functies ontwikkeld. Compliancy met deze lijst wordt ook wettelijk voor accountants verplicht om fouten van jaarrekeningen door verkeerde interpretatie van formules of afrondingen te voorkomen (een Sarbanes-Oxley vereiste). ODF zal naar verwachting deze standaard gaan gebruiken later dit jaar.
Geen spreadsheet formules is altijd nog beter dan foutieve spreadsheet formules...
Denk daar maar eens over na.
Wat heb ik aan een standaard die door alle binaire incompatibiliteiten niet op een ander platform werkt...
Een standaard moet overal werken en er mogen geen proprietaire afhankelijkheden in zitten.<PUNT>
Daar is geen discussie over mogelijk en aan beide punten voldoet OOXML NIET
Zeker de ooxml niets positiefs toevoegd. Vaak wordt er gezegd backwards compatibel, dat IMO onzin. Al je een doc file al in een ooxml file zipped kun je net zo goed helemaal omzetten naar odf.
Ik zal je mening over het 'niets positiefs' toevoegen van OOXML niet tegenspreken, helaas geeft de rest van je reactie aan dat je niet weet (of wil weten) hoe OOXML afgehandeld wordt.

Als een normaal binair Word-document namelijk in OOXML bewaard wordt, dan wordt de inhoud van het document geserialiseerd naar XML en die XML wordt gezipt. Nu ben ik jet wel met je eens dat het backwards compatible zijn (ten bate van archiveren) een drogreden is, omdat je als je een document correct wilt archiveren je veel beter PDF kunt gebruiken. PDF is namelijk ten allen tijde een garantie dat de layout hetzelfde blijft, iets wat je bij MS-Office documenten niet kunt zeggen. Er zijn soms nu al layout problemen als verschillende mensen aan eenzelfde Word-file werken...

Als men op basis van het binaire officebestand doorontwikkeld, dan is mijns inziens een waarschuwing dat er conversie issues zijn genoeg. Veel voorkomen issues kun je zelfs in een speciale helpfile zetten. (Een beetje te vergelijken met de 'Internet Explorer for Netscape users' help in IE, je zou dan een 'XML Document* voor Office gebruikers' help optie krijgen)

*: Deze naam is fictief en bewust gekozen, het is tenslotte nog mogelijk dat MS overgaat op ODF of dat er een nieuwe documentstandaard komt die ODF+OOXML samenvoegt of zelfs dat het OOXML wordt...
omdat je als je een document correct wilt archiveren je veel beter PDF kunt gebruiken
Pure onzin. Een PDfF file is een moment opname van een Office file maar niet een actief office document.
PDF bevat bijvoorbeeld niet de revisie informatie uit een Office oducment en een doorekenbaar spreadsheet rekenvel is al helemaal niet 1 op 1 te saven in PDF.
PDF is alleen geschikt voor onveranderlijke documenten zoals publicaties op papier maar zeker niet voor Office documenten.
Deze suggestie is gewoon lachwekkend en kan meteen naar de prullebak als pure FUD.
Voor het archiveren is PDF gewoon betrouwbaarder, simpelweg omdat het niet afhankelijk is van lokale instellingen.
* Little Penguin geeft direct toe dat het dan wel om een menig gaat...

Maar:
Backwards compatibiliteit wordt steeds genoemd als voorwaarde voor een op XML gebaseerd formaat, maar ik zie niet in waarom. Als je erg actief aan een document werkt kun je die paar wijzigingen echt wel handmatig doorvoren (echt grote office documenten zijn er nauwelijks omdat Word daar erg lang simpelweg niet tegen kon) of gewoon in het binaire formaat blijven werken.

Voor spreadsheets geld eigenlijk hetzelfde, als je weet welke zaken je aan moet passen dan ga je over naar het op XML gebaseerde formaat. Weet je niet wat je aan moet passen dan blijf je gewoon het oude formaat gebruiken...

Kijk als je iedereen verplicht wilt laten overstappen op OOXML, dan zorg je er voor dat ieder document standaard teruggesaved wordt als OOXML - zelfs al was de bron binair - en dan wordt een issue als backwards compatibiliteit wel belangrijk, zeker als je de gebruiker niet lastig wilt vallen met extra vragen/opmerkingen.

Toch is het beter om de gebruiker bewust die keuze te laten maken en dan een waarschuwing te geven. Het moet niet zo zijn dan we over 20+ jaar eerst tientallen vellen A4 door moeten lopen bij een implementatie van een XML-document verwerker (die dan deze OOXML moet kunnen lezen) omdat er allerlei bugs uit het verleden meegesleept zijn.

Mijns inziens moeten de op XML gebaseerde formaten een nieuwe start maken, als je backwards compatibiliteit kunt maken dmv een consequente regel dan is dat acceptabel. Het moet echter niet zo zijn dat je willens en wetens fouten gaat introduceren of fabriekant-specifieke zaken op gaat nemen in de standaard.
Effe een vraagje tussen door, waarom beschrijf je PDF enkelt als eind stadium van een document? De versioning ben je inderdaad kwijt, maar een PDF file is niets minder dan een script taaltje, zoals postscript. De binaire zooi in de PDF zijn de plaatjes in de file. Daarnaast zijn de specs van de PDF versies (netjes) gepubliceerd door Adobe en kan iedereen een lezer en schrijver voor PDF bakken.
Vandaag de dag kost opslagruimte praktisch niets meer. Sla gewoon het originele document en een PDF versie op. Aan de PDF versie kan je altijd zien hoe het eruit hoorde te zien.
Geintje hoop ik?
Of zit je om werk verlegen? Als het om 1 documentje zou gaan, zou je wat mij betreft gelijk hebben. Maar een organisatie met bijvoorbeeld 500 werknemers die ieder 20 documenten per week produceren? Zelfs al kost opslag niks meer, dat gaat toch in de snippers lopen...
<snip> of zelfs dat het OOXML wordt...
De dag dat alle moeite voor niets is geweest :'(
Als alle voorgestelde verbeteringen daadwerkelijk doorgevoerd gaan worden, dan is die nieuwe OOXML compleet anders dan de bestaande OOXML...

Interne en externe conflicten horen opgelost te zijn om maar 1 punt te noemen (er moet veel meer dan alleen dit punt opgelost worden, maar dat is een andere verhaal).

Als die nieuwe OOXML er is, dan is het misschien ook wel gemakkelijker om ODF en OOXML samen te voegen - niet dat die kans groot is, Microsoft heeft een nogal Not Invented By Us syndroom (nibu-isme)
Het is juist de bedoeling van ISO standaardisatie dat er consensus is over een standaard.
Dus als leden aangeven waarom zij tegen een standaard zijn kan de standaard aangepast worden om deze bezwaren te ondervangen.

Dat gaat dus niet zozeer omprincipes als om practische oplosssingen.
Als een ISO lid aangeeft dat ze tegen Office Open XML zijn omdat ze het principieel onjuist vinden om voor deze standaard te stemmen zal dat dus leiden tot een niet oplosbare tegenstem. Echter meeste tegenstemmen zijn op basis van praktische bezwaren die mogelijk wel kunnen worden opgelost.
Dan is de kans groot dat Microsoft en partners opeens principiele bezwaren gaan krijgen tegen de volgende versie van ODF en andere standaard-voorstellen die uit de OpenSourceCommunity komen.

Ik denk/hoop dat ze bij ISO slim genoeg zijn geweest om in hun regels vast te leggen dat dit soort geintjes niet mogen.
Grappig is in ieder geval dat de tegenstanders allerlei commentaren hebben opgeworpen waar ODF ook niet aan voldoet. Een nieuwe versie van ODF zal dus zeker niet zo maar goedgekeurd worden zolang als hhet ISO proces voor OOXML nog loopt.
Grappig is in ieder geval dat de tegenstanders allerlei commentaren hebben opgeworpen waar ODF ook niet aan voldoet.
Noem eens wat?
* Bijvoorbeeld of de licensing van een covenant not to sue geldig is buiten de VS
* Bijvoorbeeld het hergebruik van bepaalde ISO standaards
* Bijvoorbeeld het verwijderen van OLE uit de spec
* Bijvoorbeeld het verwijderen van de mogelijkheid tot het opnemen van binary elementen in de XML documenten
en dat zijn er nog maar een paar voorbeelden van comments die ook prima op Opendocument betrekking kunnen hebben.
100% correct.
De ISO procedure is ontmaskert als politiek theater, en de geloofwaardigheid van die instantie fors ondermijnt.
De blowback van dit alles zal zeker niet uitblijven, gezien de ongelofelijke hypocrysie van het commentaar op OOXML. ODF mag z'n borst gaan natmaken.
Er is niets hypocriet aan het commentaar op OOXML. 99% van het commentaar is terecht.
OOXML heeft NIETS maar dan ook helemaal NIETS met een standaard te maken.
OOXML heeft alles te maken met proberen een markt in gijzeling te houden.
Tot nu toe ben ik nog geen bedrijf tegengekomen dat voor ISO normering van OOXML is en geen 'handpop' van Microsoft is.
Ik zou niet weten waarom ODF z'n borst mag gaan natmaken

@hAl
* Bijvoorbeeld of de licensing van een covenant not to sue geldig is buiten de VS
wat heeft die überhaupt met ODF te maken. Hieruit blijkt alleen maar dat je totaal geen barst snapt van de discussie die er gaande is. Er valt niets te 'sueën' met betrekking tot ODF...
*Bijvoorbeeld het hergebruik van bepaalde ISO standaards
OOXML doet dat nu juist niet en wijkt op verscheidene punten nu juist van al bestaande ISO standaarden af ten faveure van de fouten die ze in het verleden al gemaakt hebben met diverse document formaten om maar enigszins backwards compatible te blijven...
ODF mag z'n borst gaan natmaken omdat we nou allemaal weten dat de ISO beinvloedbaar is door een stelletje onzin vertellers zoals er velen rondhangen op fora zoals deze.
Alle organisaties die met enige regelmaat dingen naar binnen flikkeren bij de ISO zijn zich op dit moment al flink achter de oren aan het krabben. 100% gegarandeerd dat er een groot aantal nieuwe partijen zullen gaan deelnemen, en een aantal oudere zal gemarginaliseerd worden.
ODF is een knudde standaard die nog lang niet af is, dat weet iedereen die er serieus mee probeerd te werken. Iedereen die iets anders zegt heeft een politiek of commercieel belang, of weet er gewoon echt geen ene fuck vanaf. Zo simpel is het.
Je bedoelt dus dat ISO z'n borst mag gaan natmaken, maar waarschijnlijk zal die organisatie z'n processen adhv het gesjoemel van MS wel gaan herstructureren...
Toch grappig dat op het werk van m'n vriendin ODF wordt gebruikt om de documenten in op te slaan. Oh wacht even... als je niet MS Office gebruikt dan zul je wel niet serieus bezig zijn...
ODF is gebaseerd op een formaat van Sun en je loopt vergelijkbare patentrisico's als met OOXML. En Sun heeft ookde patentrechten vrijgegeven met een covenant not to sue net asl Micrsoft. Dus als dat een probleem is in andere landen dan geldt dat ook voor het covenant van Sun

ODF wijkt ook veelal af van ISO standaarden. Zo zijn MathML en SVG en Xlink bepaald geen ISO standaarden. Zover ik kan zien staan er maar 3 ISO standaarden genoemd in ODF en die staan ook alledrie in OOXML..
Grappig is in ieder geval dat de tegenstanders allerlei commentaren hebben opgeworpen waar ODF ook niet aan voldoet.
Ja, da's grappig ja. Triest is dat het falen van ODF wordt aangevoerd als reden waarom OOXML mag zuigen.
Als je gewoon uit principe tegenstemt omdat het een microsoft standaard is, dan vraag ik me af of je recht hebt op deelname in een onafhankelijke instantie die zich over de geschiktheid van standaarden moet buigen.
Zelfde geldt ook voor de mensen die uit principe voorstemmen ongeacht wat er in de standaard staat omdat ze pro-microsoft zijn, die horen er ook niet te zitten.
Het schijnt dat een lid van de Nederlandse commissie die stemde over OOXML voor ISO beweerde de opdracht gekregen hebben tegen OOXML te stemmen wat er ook uit de discussies binnen de commissie mocht vloeien, volgens mij was het stichting Vrijschrift, maar ik weet het niet zeker.
Dat is al net zo erg als al die principiële voor-stemmers (lees: door Microsoft betaald)...
En jij weet dat MS partners betaald heeft, omdat?
Zoekt en gij zult vrij snel vinden.
Nee dat zal ik niet omdat wat je zegt onzin is.
NIet al te gek, als ODF al bestaat en dat OOXML structeren in zich kan embedden en capsuleren in een andere formaat dat niet in de specs hoeft te (lees: zal) staan.

Maar het moet niet zo zijn dat het een bash tegen microsoft ontwikkelingen is. Er werken zeker ook slimme mensen daar. Ik denk dat dit vooral het werk is van de slimme sales en PR afdelingen om de stempel 'open standards compliant' op de dozen van Office 2009 te krijgen met als doel om niet door allerlei overheids instanties over de wereld er uit gekickt te worden.

Het is op zich gewoon belachelijk dat we in Nederland voor overheid en bedrijfsleven zo sterk in de tang zitten bij Microsoft met de Office document formaten (alle versie van 97 tot 2007). Ik denk dat ze bij Redmond wel weten waar The Netherlands ligt.

[Reactie gewijzigd door VisionMaster op 5 september 2007 01:51]

Las ik niet ergens dat ze de boel geflest hadden door snel partners lid te maken van de nationale clubs die de stemming bepalen ? Doe je zoiets in de politiek dan draai je de bak in maar hier gaat MS weer ongestraft zijn gang. En zelfs dan lukt het ze vooralsnog niet.
Dat heb je goed gelezen. In meerdere landen hebben ze hun 'gold partners' op het laatste moment lid laten worden van de nationale commissies and mee laten stemmen. Commissies die uit 8 personen bestonden met 6 tegenstemmers zagen twee dagen voor de stemming ineens 15 nieuwe leden binnenkomen die allemaal voor stemden. Rara pindakaas.

Ben benieuwd hoe mevrouw Kroes hierop reageert.
Er is geen enkel bewijs dat MS hun gold partners lid hebben laten worden van de diverse commissies, dan wel met of zonder dwang.

Het enige dat opgemerkt kan worden is dat er de laatste periode met name Microsoft Gold Parters lid zijn geworden van de dergelijke clubs.

Graag bij de feiten blijven en niet conclusies trekken.
August 30, 2007 (Computerworld) -- Microsoft Corp. admitted Wednesday that an employee at its Swedish subsidiary offered monetary compensation to partners for voting in favor of the Office Open XML document format's approval as an ISO standard.
Microsoft admits Swedish employee promised incentives for Open XML support
van os2world.com:

Swedish newspaper, Computer Sweden, now confirms that Microsoft did send out e-mails to get Gold Partners to get them to vote via one of the Gold Partners that received the e-mail and phone calls from Microsoft.
De feiten? Waar zijn de feiten dan? Geloof jij nu werkelijk dat je de 'echte' feiten te zien krijgt?

Sorry, maar da's wel erg naief vooral vanwege het feit dat Microsoft veeeelen rot
streken heeft uitgehaald en er nog veeeelen zal uithalen.

[Reactie gewijzigd door SassieST808|IA op 5 september 2007 09:27]

Ik verwacht helemaal niks, mijn kritiek is gebaseerd op de uitspraken die in andere posts worden gedaan. Overigens zal mij het een worst zijn of die standaard er nou wel of niet komt. Lig er geen moment wakker van eigenlijk.

Het mooie van een standaard is dat er geen rechten aan ontleend kunnen worden. Het is geen eigendom van MS of van welke organisatie ook. Tevens betekent dat iedere andere organisatie de standaard kan toepassen. Want deze is immer geheel vrij gegeven!

Verder wat stond er in die brieven en wat is er besproken in de telefoongesprekken? Vroegen ze dat ze het op prijs stelden als die gold partners lid zouden worden en voor zouden stemmen? Of stond er als je niet lid wordt en voor stemt trekken we gold partnership in? Het is een kwestie van intepretatie.
Ben benieuwd hoe mevrouw Kroes hierop reageert.
Niet. Dit gaat over ISO-standaarden, daar heeft de EU niets over te zeggen, laat staan een of andere dame die zich bezig houdt met mededingingszaken...
Dat deden beide partijen.
Zo werden tyegenstanders Google en Redhat in de VS ook op de laatse meeting dat dat nog kon in de VS lid van het V1 committee om tegen te stemmen.
Maar die werden niet betaald om lid te worden door de tegenstanders van OOXML...
zij zijn namelijk zelf de tegenstanders
Link naar het bewijs dat MS partners heeft betaald graag.
Volg jij überhaupt het nieuws?
Zoek maar op Zweden, OOXML en standard.
Misschien moet je Groklaw eens bekijken.
En ja: de inschrijvingskosten betalen voor een partner vind ik betalen.
Ik volg het nieuws best wel goed, maar toch heb ik nergens kunnen vinden dat MS z'n partners betaald heeft.
Toch heb jij het al een paar keer geroepen op deze pagina.
Als ik het niet al wist zou ik vragen waarom.
13 uur voor je post heeft Maurits van Baerle (bovenstaand) een link geplaatst, secuur lezen is belangrijk om een mening te vormen. In het artikel, terwijl vast staat dat er een mail uit is gegaan met een oproep, maakt MS een enorme 'spin' op het hele verhaal.
"We had a situation where an employee sent a communication via e-mail that was inconsistent with our corporate policy," said Tom Robertson, general manager for interoperability and standards at Microsoft. "That communication had no impact on the final vote."
Ok, ik heb het zo secuur mogelijk gelezen en toch nergens gevonden dat MS z'n partners betaald zou hebben.
Misschien moet je het even uitleggen, of anders gewoon ophouden met onzin spuien?
mja is dat flessen of lobby-en... het zit er ergens tussenin...

In Nederland hebben ze de NEN gedreigd met een rechtzaak als de NEN tegen zou stemmen (wat de NEN wilde doen), omdat de NEN een procedurefout had gemaakt bij het oprichten van de comissie die over ooxml moest besluiten. Onder de dreiging van een rechtzaak heeft de NEN blanco gestemd. Ook dat ligt ergens tussen lobby-en en flessen in...
Ik hoop dat er inderdaad wijzigingen komen met betrekking tot de ooxml specificatie. Dat kan alleen maar meer positiviteit brengen. Ook al vindt ik nogsteeds dat er twee onafhankelijke office producten moeten zijn die beide (dus ook ODF) inplementeren voordat we echt van een open standaard kunnen spreken.
ik weet niet of je dat als kritiek op ODF doelde, maar er zijn inmiddels er een heleboel onafhankelijke office producten die ODF implementeren: Abiword, ajaxWrite, Coventi Pages, Google Docs and Spreadsheets, IBM Lotus Productivity Tools Documents, Ichitaro , KWord , OpenOffice.org (en derivaten zoals NeoOffice, Sauver.Office en StarOffice), TextEdit, TextMaker en Zoho Writer.
Microsoft heeft dit weer goed bekeken.

Nu hebben ze tijd om in de comitees ongemerkt Microsoft partners te laten aansluiten vooraleer de volgende stemronde begint om dan hun standaard er in één keer door te drukken.

Dit komt bij mij op als ik de berichtgeving van de vorige weken hier bekijk.

Lekker wat PR doen om alles wat er gebeurd is te doen vergeten.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True