Versnelde ooxml-standaardisatie stuit op weerstand

Microsofts plan om de ooxml-specificatie versneld goedgekeurd te krijgen door de ISO heeft enige vertraging opgelopen. Binnen het Amerikaanse nationale ISO-comité was namelijk niet de benodigde meerderheid te vinden.

De International Organization for Standardization (ISO) heeft begin maart het proces in gang gezet om de 'Office Open XML'-standaard versneld goedgekeurd te krijgen. Zoals gewoonlijk bij dit soort processen moet ieder betrokken land vervolgens zijn goed- dan wel afkeuring uitspreken. In het geval van Amerika is afgelopen vrijdag gestemd over het ooxml-voorstel en bleek dat er van de 26 leden 10 voor- en 15 tegenstemden; het laatste lid onthield zich van stemming. De Amerikaanse organisatie zal op dit moment bij de ISO dus niet zijn goedkeuring aan de ooxml-standaard verlenen, maar ook over afkeuring of zelfs over een 'geen mening' kon de werkgroep geen overeenstemming bereiken.

Nu de stemmen weer staken, gaat het International Committee for Information Technology Standards het commentaar van de Amerikaanse werkgroep verwerken. Als dit gedaan is, worden er twee nieuwe stemrondes georganiseerd, waarbij de tweede stemming gebruikt kan worden om de in de eerste stemronde uitgebrachte stem te wijzigen. Dit stemproces moet op 2 september zijn afgerond. Op die datum kan dan worden vastgesteld of de standaardisatie van ooxml via het snelle of via het normale traject moet plaatsvinden. Dat is namelijk niet alleen afhankelijk van de stemming in het Amerikaanse comité, maar ook van de stemmingen in andere landen. De meeste van die landen hebben voor verlenging of annulering van het snelle traject gekozen, wat inhoudt dat het normale standaardiseringstraject moet worden bewandeld.

ODF-plugin voor Word 2007

Microsoft had erop gehoopt dat het snelle traject genomen kon worden. Het aantal wijzigingen in de ooxml-standaard was dan beperkt gebleven. Daarnaast kon dan eerder begonnen worden met het afsluiten van Office 2007-contracten met overheden, die in toenemende mate ISO-certificering eisen voor belangrijke onderdelen van de software die ze gebruiken. Mocht het allemaal niet lukken met de standaardisering van ooxml, dan hoeft men bij Microsoft niet te treuren. Office 2007 kan namelijk uitgebreid worden met support voor het OpenDocument-formaat, de grootste concurrent van ooxml en al wel een ISO-standaard. Het Redmondse bedrijf zal zijn software dus nog steeds kunnen verkopen. Daarnaast geldt dat ooxml de facto alsnog dé standaard zal worden, omdat Microsofts kantoorsoftware nu eenmaal het meest gebruikt wordt.

Reacties (63)

[Daimanta]

Vind MS het heel gek? Ooxml is helemaal niet open.

Voorbeeld van een ooxml functie:

setSpacesLikeWord95

Vertel mij dan eens. Hoe doet Word95 dat dan? Hoe moet je daar achterkomen? Word95 reverse-engineeren zeker?

Als MS een ISO certificering voor ooxml wil, dan moeten ze ooxml ook daadwerkelijk open maken.

[YaPP]

OOXML is inderdaad niet open. Belijk de volgende vragenlijst, en bedenk vragen (vetgedrukt) welke Microsoft positief kan beantwoorden:
http://fsfeurope.org/documents/msooxml-questions

Dat zijn namelijk wel eisen die aan een open standaard gesteld worden:
1. het moet niet afhankelijk zijn van 1 specifiek besturingssysteem.
2. bij voorkeur doorbouwen op bestaande standaarden (bijvoorbeeld voor formules, datums, tijden en vectortekeningen).
3. zonder beroep te moeten doen op support moet je de software kunnen bouwen
4. er mogen geen ongedocumenteerde uitbreidingen bestaan.
5. er mag geen dubbele standaard zijn. (MS is lid van de ODF commissie, maar geeft niet door wat er aan ODF ontbreekt om het in Office te ondersteunen).
6. het is juridisch veilig om de standaard in je product te implementeren.

Iedere open standaard hoort deze vragen met "ja" te kunnen beantwoorden. OOXML kan dat niet.

[Reactie gewijzigd door YaPP op 22 juli 2024 15:13]

[Verwijderd]

1. OOXML is al beschikbaar op Novell Linux en komt in de volgend Office verise voor Apple ook beschikbaar. Ook de Apple iPhone herkent OOXML files
2. OOXML herbruikt ook bepaalde standaarden en niet specifiek minder dan bijvoorbeeld ODF. ODF gebruikt met name meer W3C standaarden maar met name een aantal waarvoor ISO ook al ee nstandaard had en die door OpenDocument zijn genegeerd.
3. Er is geen aanwijzing dat je voor implementatie van OOXML meer support nodig hebt dan voor implementatie van ODF. aan de andere kant bestaan er na twee jaar nog geen volledige implementaties van ODF dus misschien hebben ODF applicaties juist wat extra support nodig.
4 Hmmm, problematisch. Je kun OpenDcoument volledig ongedocumenteerd uitbreiden. Sterker nog, dat heeft OpenOffice al gedaan met ongedocumenteerde compatibility office settings. Aan de andere kant kun je dat ook met OOXML custom settings. Echter de voornaamste methode van extensibilty in OOXML vereist dat je openbare XML schema's gebruikt. De syntax wordt daarmee volledig gedocumenteerd. Die extentibility is veel duidelijk beschreven in OOXML danbijvoorbeeld ODF extentibility !!
5 MS is geen lid van een ODF commissie. MS is lid van OASIS waarbinne talloze standaarden woren ontwikkeld. Microsoft is daarin alleen betrokken in commiseis die te maken hebben met Service Oriented Archtecture. Verder mag er best een dubble standaard zijn maar mag standaarden elkaar niet tegenspreken. Twee standaarden mogen bijvoorbeeld niet elk op een andere manier definieren wat een meter is. Overigens zijn er zat verschillen en zijn velen daarvan ook wel door Microsoft aangegeven. Een voorbeeld is dat OOXML qua structuur en specificatie veel meer is gericht op performance optimalisatie.
6 Ja je kunt OOXML net zo veilig in je product implementeren als ODF. Ik heb nog geen voorbeeld gehoord van een document dat je juridisch kan implementeren met ODF wat je niet kan implementeren met OOXML.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 15:13]

[YaPP]

1. het moet niet afhankelijk zijn van 1 specifiek besturingssysteem.1. OOXML is al beschikbaar op Novell Linux en komt in de volgend Office verise voor Apple ook beschikbaar. Ook de Apple iPhone herkent OOXML files

De vraag is of een ander systeem het voor 100% kan ondersteunen.

OOXML gebruikt WMF en "windows clipboard data". Dat zijn zaken die niet buiten Windows werken. Beidde bestaan uit GDI opdrachten voor Windows.

2. bij voorkeur doorbouwen op bestaande standaarden (bijvoorbeeld voor formules, datums, tijden en vectortekeningen).
OOXML herbruikt ook bepaalde standaarden en niet specifiek minder dan bijvoorbeeld ODF. ODF gebruikt met name meer W3C standaarden maar met name een aantal waarvoor ISO ook al een standaard had en die door OpenDocument zijn genegeerd.

Kun je dat beter beargumenteren?

deze lijst geeft aardig weer welke standaarden genegeerd worden, of op een incompatibiele manier worden toegepast.

3. zonder beroep te moeten doen op support moet je de software kunnen bouwen
Er is geen aanwijzing dat je voor implementatie van OOXML meer support nodig hebt dan voor implementatie van ODF. aan de andere kant bestaan er na twee jaar nog geen volledige implementaties van ODF dus misschien hebben ODF applicaties juist wat extra support nodig.

Je opmerking is bijzonder suggestief, en beantwoord de vraag over OOXML niet.

Er is inderdaad nog geen volledige ODF implementatie. De standaard is verder gegaan dan wat er in OpenOffice of KOffice ondersteund wordt. Er is echter een testsuite waarmee beidde office pakketten kunnen controleren wat ze nog nodig hebben. Hulp is dan ook niet nodig; als in de applicatie iets niet werkt is in de ODF specificatie na te lezen hoe het moet werken. Dat is het idee van een open standaard!

OOXML beschrijft bepaalde zaken niet. Hoe bepaalde borders, marges of compatibility-opties gerendered moeten worden is onduidelijk. Dat betekend dat andere pakketten OOXML nooit zogoed kunnen renderen als Office dat kan. Vergelijk maar met het niveau van .doc ondersteuning in Open Office. Ook als er een testsuite voor OOXML uitkomt, kunnen concurrenten niet nagaan hoe het dan wel moet werken.

Dat is een slimme strategie die Microsoft al langer uitvoert, en je hoeft daar niet op in te gaan. Ze proberen echter OOXML tegelijk voor te laten doen als "open standaard", wat bepaalde eisen stelt aan een formaat. En die eisen zijn tegenstrijdig met hetgeen wat Microsoft probeert (de standaard beperkt bruikbaar houden). Overheden vereisen tegenwoordig open standaarden om goede ondersteuning te garanderen; voor het formaat waarin ze hun informatie opslaan. Microsoft zit nu in een splagaat: hun monopolie is afhankelijk van gesloten formaten waar zij zelf beter in zijn. OOXML is ook op die manier opgebouwd, maar probeert alleen toch binnen te komen als "open standaard". Een vos is schaapskleren dus.

er mogen geen ongedocumenteerde uitbreidingen bestaan.
Hmmm, problematisch. Je kun OpenDcoument volledig ongedocumenteerd uitbreiden

Daar heb je een heel goed punt, klopt helemaal. Je kunt een bestandsformaat namelijk altijd uitbreiden.

Mijn formulering had ook anders moeten zijn: de bestaande documentatie moet 100% open zijn, niet gesloten delen bevatten. Dat andere partijen daarnaast hun eigen gesloten uitbreidingen maken staat dan los van de standaard.

5. er mag geen dubbele standaard zijn. (MS is lid van de ODF commissie, maar geeft niet door wat er aan ODF ontbreekt om het in Office te ondersteunen).
MS is geen lid van een ODF commissie. MS is lid van OASIS waarbinne talloze standaarden woren ontwikkeld.

Daar heb je inderdaad gelijk in. Mijn punt is meer, ze hebben de kans gehad om door te geven welke functionaliteiten er ontbreken in ODF om het goed in Office te ondersteunen. Microsoft kiest er echter voor de uitnodiging af te wijzen, en op een later moment de ontbrekende ondersteuning te gebruiken als tegenargument voor ODF.

6. het is juridisch veilig om de standaard in je product te implementeren.
Ja je kunt OOXML net zo veilig in je product implementeren als ODF. Ik heb nog geen voorbeeld gehoord van een document dat je juridisch kan implementeren met ODF wat je niet kan implementeren met OOXML.

Dan moet je je beter inlezen in de materie. Er is voor andere partijen een risico dat Microsoft je kan aanklagen voor patentinbreuk. De patentvrijwaardig van Microsoft geld niet voor de optionele delen van OOXML, of de gesloten formaten die het ook gebruikt.

Efectief kun je dus OOXML maar deels implementeren, concurrenten zullen altijd een gebreken hebben voor ondersteuning van het formaat. En dat is precies de truc die Microsoft probeert uit te halen: wel het formaat laten voordoen als open standaard (om overheden over te halen) door goedkeuring binnen krijgen. Een aantal jaren verder wordt duidelijk dat het toch niet helemaal open was als beloofd. Voor Microsoft is dat ook een win-win situatie: concurrentie is dan weer voor een paar jaar tegengehouden.

Wat nog enger is dat Microsoft hard bezig is deze standaard - ondanks alle tegenstand - door te duwen:

http://www.kletskous.com/...is-niet-blauw-maar-groen/

# De technische commissie die in de VS over de standaard adviseert, bestond tot aan vorige maand uit 7 leden; inmiddels bestaat deze commissie uit 26 leden, waarvan er 16 nog in de laatste maand voor stemming toetraden. Het overgrote deel van de neuwe leden bestaat uit Microsoft Business Partners zijn. Van de 7 leden van het eerste uur, stemden er zes tegen de acceptatie; een ervan, Microsoft, stemde voor. Van de 16 nieuwste leden, stemden er 14 voor. Overigens werd net dit net niet de vereiste 2/3de meerderheid behaald, die nodig is. Ook in veel andere landen vindt een invasie plaats van Microsoft partners in de technische commissies.
# In Portugal werden Sun en IBM - tegenstanders van Open XML - de toegang tot de vergadering ontzegd, omdat er te weinig stoelen waren, terwijl de zaal vol zat met Microsoft mensen.

[Reactie gewijzigd door YaPP op 22 juli 2024 15:13]

[Verwijderd]

Daar heb je gelijk in. Mijn punt is meer, ze hebben de kans gehad om door te geven welke functionaliteit er ontbreken in ODF om het goed in Office te ondersteunen. Micrsoft kiest ervoor de uitnodiging af te wijzen.

Welke uitnodiging bedoel je ? Ik heb geen concrete brief gezien van het OASIS committe aan Microsoft.
In de eerste bijeenkomst van de OASIS TC is gekozen om het Open Office format te gebruiken als basis voor het toenmalig te ontwikkelen Open Office XML formaat en is meteen vastgelegd dat compatibiliteit met bestaande Office documenten geen requirement for het nieuwe formaat zou zijn.

[kidde]

Dus, in plaats van te vragen of OASIS rekening wilde houden met miljarden Microsoft-office gebruikers deed Microsoft helemaal niets en speelde stommetje, ondanks dat ze lid waren. Feit is dat Microsoft destijds namelijk incompabiliteit zo veel mogelijk wilde dwarsbomen, het zoveel mogelijk vertragen van het vrijgeven van het SMB-protocol (meer dan tien jaar op gewacht, maar nog steeds niet afdoende vrijgegeven, zelfs niet na boetes van honderden miljoenen) bewijst dit. Pas toen bleek dat ODF niet uit zichzelf doodbloede, kon Microsoft zich geen gezichtsverlies permitteren door alsnog te vragen aan OASIS, waar ze lid van waren, of het een en ander veranderd kon worden, en vroeg het ECMA een standaard te schrijven conform de (toen) huidige Office-formaten, om daar dan vervolgens een ISO-stempel bij proberen te krijgen. Helaas voor Microsoft, gelukkig voor het bedrijfsleven, lijkt het erop dat het ISO hier niet in gaat trappen. Het zou het bedrijfsleven namelijk miljarden kosten keer op keer te moeten converteren tussen verschillende ISO-standaarden voor hetzelfde doel (zeker met de kreupele Microsoft-converter, de slechtste converter van de minstens drie die beschikbaar zijn), en meerdere ISO-standaarden voor hetzelfde doel levert in dit geval alleen Microsoft miljarden op. Gelukkig is het befrijfsleven niet dom, wat is gebleken door de vele kritiek op de fast-track procedure, door Microsoft bedoeld als 'onzichtbare bliksemactie' om een ISO-stempel voor OOXML te verkrijgen zonder dat de wereld dit door zou hebben.

Tevens is de nieuwe OOXML standaard ook helemaal niet compatibel met bestaande Office-documenten, omdat erin niet gespecificeerd is hoe de oude .doc documenten in elkaar steken, deze blijven 'closed format', dus OOXML _IS_ helemaal niet compatibel met oude standaarden, en daarmee gaat het belangrijkste bestaansrecht van OOXML al verloren.

[Verwijderd]

Dus, in plaats van te vragen of OASIS rekening wilde houden met miljarden Microsoft-office gebruikers deed Microsoft helemaal niets en speelde stommetje, ondanks dat ze lid waren.

Als Microsoft een groepje afvaardigt in OASIS om daar zich bezig te houden met Serive Oriented Architecture waarom zouden die zich dan geroepen voelen om zich bezig te gaan houden met een groepje die de interoperabiliteit van het OOo document format willen verbeteren en die al vooraf een TC groep hadden geformeerd van geintereseerden in StarOffice/OpenOffice en daarbij helemaal MS niet hebben benaderd.

[Verwijderd]

OOXML gebruikt WMF en "windows clipboard data"

Pure onzin. OOXML gebruikt geen WMF of clipboard data net zoals ODF geen java gebruikt. Je kunt echter wel WMF of clipboard elementen aan een OOXML toevoegen net zoals je java applets aan ODF kan toevoegen. Wat OOXML heeft gedaan is bij het embedden van objecten aparte types te definieren voor WMF of clipboard objecten zoals ODF aparte embedding heeft gedefinieerd voor java applets. Dat is dus prima te ondersteunen op een ander platform. Het embedede object is misschien niet te ondersteunen maar het lezen van het in ooxml gedefinieerde formaattype en daarmee het embedde object herkennen kan je op elk platform.
Je kun WMF objecten en clipboard objecten trouwen ook in ODF documenten embedden. Alleen kun je ze daar alleen herkennen of door de extentie of door het inlezen van het binarie object en natuurlijk kan je ze dan ook niet op een ander platform openen.

Hulp is dan ook niet nodig; als in de applicatie iets niet werkt is in de ODF specificatie terug te vinden hoe het moet werken. OOXML beschrijft bepaalde zaken niet. hoe bepaalde border, marges of compatibility-opties gerenderd moeten worden is onduidelijk.

Je zit het gewoon te verzinnen. De Opendocument bevat helemaal geen goede informatie over hoe je documenten moet renderen. Als dat niet goed werkt moet je zeker niet in de standaard kijken.

Ik heb wel een voorbeeldje hoor. Uit de ODF spec:

15.11.4Vertical Glyph Orientation
The style:glyph-orientation-vertical property specifies the vertical glyph orientation. The property specifies an angle or automatic mode. The only possible angle is 0, which disables this feature.
<define name="style-table-cell-properties-attlist" combine="interleave">
<optional> <attribute name="style:glyph-orientation-vertical"> <choice>
<value>auto</value>
<value>0</value>
</choice> </attribute> </optional> </define>

Afgezien wat een glyph is wordt hier de orientatie van een Glyph beschreven. Ik veronderstel dat jij of een willekeurige gebruiker hieruit meteen kan zien hoe je glyph moet orienteren. Vooral lachen dat de enige values bestaan uit automatic en nul. Dat maakt het natuurliik allemaal meteen duidelijk. Dit is een typisch voorbeeld van extreem onduidelijke specs in ODF die geen mens kan implementeren. Volgens jou kan ik uit de spec halen hoe het moet werken. Volgens mij begrijp je er geen ruk van en heb je de ODF spec nog nooit bekeken want dat is een redelijke syntax beschrijving maar hoe die syntax te interpreteren is erg complex en niet beschreven !!

Dan moet je je beter inlezen in de materie. De patentvrijwaardigheid geldt niet voor de optionele delen van OOXML, of de gelosten formaten die het gebruikt

Ook dit klinkt weerr als pure lucht zonder enig aantoonbaar bewijs. Welke optionele delen van OOXML bedoel je ? In feite zijn namelijk alle delen van OOXML optioneel. Bovendien gebruikt ooxml geen gesloten formaten. Je kunt wel gesloten formaten n ooxml embedden maar dat kun je ook in ODF. Dat levert dezelfde juridisch issues op. Ik herhaal, noem mij eens een voorbeeld van een office document dat ik wel in ODF mag aanmaken en niet in OOXML vanwege licentieproblemen. Diverse juridische experts hebben al de openheid van OOXML bevestigd waaronder zelfs een bekend opensource advocaat.

[Verwijderd]

Voorbeeld van een ooxml functie:

setSpacesLikeWord95

Vertel mij dan eens. Hoe doet Word95 dat dan? Hoe moet je daar achterkomen? Word95 reverse-engineeren zeker?

Aan de andere kant is de vraag, hoe doet ODF dat.
Nee, niet spaces zoals in Word 95 maar gewoon in ODF 1.0.
In die spec staat namelijk helemaal niet hoe spacing in ODF werkt.
In OOXML ook niet.
Het zou dus heel vreemd zijn om uit te leggen hoe spacing in Word 95 afwijkt van normale spacing omdat iedere applicatie die een office document rendert op basis van deze spec zelf kan besluiten hoe een space eruit ziet.

Op basis van deze spec kun je over een document echter wel zeggen dat een geconverteert document alleen identiek rendert als je het open in word 95 wat vermoedelijk eigenlijk alleen voor speciale archief documenten relevant kan zijn.

Overigens kun je in ODF ook afwijkende legacy compatibility opnemen. Zo bevatten naar ODF geconverteerde OpenOffice documenten bijvoorbeeld ook Office setting waarin staat "UseFormerLinespacing". Maar in OpenOffice zijn dat vrije ongedocumenteerde en niet unieke waardes. Je kunt aan dergelijke settings niet eens zien door welke applicatie ze aan het document zijn toegevoegd laat staan dat je erachter kan komen wat ze betekenen.

[Cheetah]

Ooxml is helemaal niet open.
Voorbeeld van een ooxml functie:
setSpacesLikeWord95

Vertel mij dan eens. Hoe doet Word95 dat dan? Hoe moet je daar achterkomen? Word95 reverse-engineeren zeker?

Verassend dat je uit de naamgeving van een functie kunt afleiden dat deze niet open is.
Ik kan je garanderen dat ik als softwareontwikkelaar regelmatig functies met veel vreemdere naamgeving tegen kom.

Zolang er is - of wordt - gedocumenteerd wat de implementatie van zo'n functie is, hoe hij gebruikt moet worden en welk resultaat verwacht mag worden is dit geen enkel probleem.
What's in a name?

Dit is een typisch geval van stemmingmakerij op basis van een naampje, zoals ik verder naar benenden in deze thread in de petitie tegen OOXML ook zie. Het lijkt dus weer eens sterk over vorm, en niet over de inhoud te gaan.

Laten de tegenstanders maar eens met een goed betoog komen wat er inhoudelijk mis is met OOXML en hoe het gestandaardiseerde ODF 1.0 dat beter doet... en dat dan ook zetten tegen een betoog waarin de voordelen van OOXML t.o.v. ODF 1.0 besproken worden, want die zijn er ook.
Leken een rad voor de ogen draaien en een standaard verwerpen op basis van de naamgeving van sommige functies is toch wel erg triest i.m.h.o. Ik denk ook dat dat is wat m3taverse bedoelt.

Ik zeg bewust ODF 1.0 gezien het nieuwe ODF format niet gestandaardiseerd is. Net zoals issues met ODF gefixed kunnen worden kunnen ook OOXML issues gefixed worden.

[Reactie gewijzigd door Cheetah op 22 juli 2024 15:13]

[Maurits van Baerle]

Laten de tegenstanders maar eens met een goed betoog komen wat er inhoudelijk mis is met OOXML en hoe het gestandaardiseerde ODF 1.0 dat beter doet...

Dat is natuurlijk een beetje vreemde opmerking. Die betogen worden al zeker twee jaar gevoerd. Er zijn hele uitgebreide opsommingen met bugs, onhandige design keuzes, incompatibiliteiten, negeren van bestaande standaarden (ISO8601!) etc. overal op het web te vinden. Zowat elke twee weken wordt er wel weer ergens een nieuwe fout gevonden die uitgebreid wordt uitgeplozen. Regelmatig worden er protesten ingediend door vertegenwoordigers van specifieke bedrijfstakken of wetenschappen die ineens ontdekken dat er een standaardvoorstel met fouten is ingediend die voor hun sector verregaande gevolgen kan hebben.

Als jij je nou eerst eens inleest...

The Formula for Failure (Incomplete en buggy formule implementaties)
Microsoft Office dumped by Science and Nature (Formules en berekeningen zijn te onbetrouwbaar)
Problemen met incompatible datum formaten (Zelfs met andere MS formaten)
Het ten onrechte beschouwen van het jaar 1900 als schrikkeljaar
De features uit ODF die ontbreken in OOXML
Het hard coderen van zaterdag en zondag als 'weekend' (In niet Christelijke landen valt het weekend nogal eens op andere dagen)
Het niet hanteren van bestaande taal en land standaarden maar op eigen houtje een lijstje maken. (Hierdoor missen er sommige talen, landen en regio's en ontstaan compatibiliteitsproblemen met andere formaten)
The Technical Case Against DIS 29500/OOXML
EOOXML objections

Het heeft vooral te maken met het proces. OASIS, de organisatie die de ODF standaard maakt, doet dat in een open Technical Committee. Iedereen kan de discussie meevolgen. Ziet iemand vanuit zijn of haar eigen expertise een potentieel probleem opduiken dan kan het gemaild worden en wordt het besproken. Er is open discussie met gehandicaptenorganisaties, diverse standaardenorganisaties, hele bedrijfstakken, wetenschappers, standaardenexperts, archiveringsdeskundigen, beveiligingsdeskundigen etc. Allemaal kijken ze mee over de schouders van de TC en allemaal kunnen ze voorstellen voor verbeteringen of uitbreidingen doen. Ook jij kan dat.
Op deze wijze is destijds ODF 1.1 ontstaan en inmiddels ook goedgekeurd. Gehandicaptenorganisaties hadden opmerkingen over potentieele problemen met dingen als Screen Readers en hebben contact opgenomen met OASIS. Die hebben met die organistaties en accessibility-experts om de tafel gezeten en daar is uiteindelijk ODF 1.1 uit voort gekomen.
Op dezelfde manier is er het afgelopen jaar over ODF 1.2 gesproken en aan ontwikkeld. ODF 1.2 zal later dit jaar ter standaardisering worden ingediend.

Het EOOXML proces is compleet anders gegaan. MS heeft een deel van haar MOOXML standaard openbaar gemaakt en bij ECMA naar binnen gegooid. Die hebben er nauwelijks naar gekeken en er een handtekening onder gezet. Hadden zij er beter naar gekeken, en bijvoorbeeld de tekortkomingen gezien, dan had er nog wat aan kunnen gebeuren. MS heeft zich uiteindelijk zelf in de vingers gesneden door achter gesloten deuren (en waarschijnlijk gehaast) iets in elkaar te draaien en er niet kritisch naar te laten kijken, Nu ligt het formaat bij het ISO en daar worden de tekortkomingen ineens als tegenargument gebruikt. Iets wat tussentijdse evaluatie en reparatie had kunnen voorkomen.

[Reactie gewijzigd door Maurits van Baerle op 22 juli 2024 15:13]

[Verwijderd]

Het EOOXML proces is compleet anders gegaan. MS heeft een deel van haar MOOXML standaard openbaar gemaakt en bij ECMA naar binnen gegooid. Die hebben er nauwelijks naar gekeken en er een handtekening onder gezet

Vreemde bewering. Er is namelijk een enorm verschil in de standaard die door Microsoft aan Ecma is aangeleverd en de standaard die uit de Ecma TC is gekomen. Zo is de spec tijdens de bijna een jaar durende Ecma standardisatie duizenden pagina's gegroeid.

Verder zijn er vier publieke beta versie gepubliceerd op de Ecma site en kon je je commentaar daarop gewoon naar de Ecma TC sturen of indien gewenst zelfs uiten op blogs van leden van deze TC. De 1.3 publieke beta versie is al in mei 2006 bij ISO JCT1 ingediend zodat ook ISO members al ruim op tijd zich konden inlezen.
Volgens mij heeft OASIS tijdens ODF standaardisatie niet eens vier publieke draft versies opgeleverd.

[kidde]

ECMA is een gesloten prive organisatie waar niet zomaar iedereen lid van kan worden, en al zeker niet iedereen kan er stemrecht krijgen.

Er is namelijk een enorm verschil in de standaard die door Microsoft aan Ecma is aangeleverd en de standaard die uit de Ecma TC is gekomen.

Zal zeker zo zijn. Helaas zijn de mailing-lists van ECMA niet publiekelijk toegankelijk, zoals bij OASIS wel het geval, dus buiten ECMA weet niemand hoe dit gegaan is.

Volgens mij heeft OASIS tijdens ODF standaardisatie niet eens vier publieke draft versies opgeleverd.

Dat was ook niet nodig, omdat het vanaf het begin open was:

Het OpenOffice formaat kwam voort uit het XML community project, waarbij iedereen kon helpen. In 2003/4 zijn er veel fouten uit dit formaat gehaald, en de formaten zijn toen aangepast aan de hand van nieuwe XML technieken.
Toen OASIS ontstond, kon iedereen (in tegenstelling tot ECMA) daarvan lid worden, bijna iedereen, NGO's inclusief, kon (wederom in tegenstelling tot bij ECMA) stemrecht verwerven, de mailing-lists lezen en inspraak leveren, en er zijn drie publieke drafts geweest.

[Reactie gewijzigd door kidde op 22 juli 2024 15:13]

[Verwijderd]

Dergelijke opmerkingen brengen even weinig bij aan de discussie. Als het niet klopt, wees dan zo vriendelijk te zeggen wàt i.p.v. met scheldwoorden te gooien.

[Verwijderd]

Microsoft probeert OO-XML gestandaardiseerd te krijgen terwijl er al een goede standaard is namelijk ODF.

Ik heb toevallig vandaag nog geblogged over OO-XML.

uit http://ubuntudemon.wordpr...7/07/18/say-no-to-oo-xml/ :

Microsoft is trying to push their inferior OO-XML office file format specification as a standard. The existing ODF office file format standard is superior and is already implemented by all major office suites (except by MS Office). The OO-XML specification has big problems and is designed to be hard to implement. For example to be able to implement “autoSpaceLikeWord95” or “useWord97LineBreakRules” you would have to reverse-engineer these proprietary applications.Sign the petition and say NO to OO-XML. http://www.noooxml.org/petition

If you are dutch read : http://www.noooxml.org/petition-nl and
http://www.kletskous.com/...is-niet-blauw-maar-groen/

[Reactie gewijzigd door Verwijderd op 22 juli 2024 15:13]

[SirBlade]

Op welke vlakken is OOXML inferieur aan ODF? Zaken als "setSpacesLikeWord95" zullen duidelijker verwoord moeten worden maar dat maakt ODF op zich niet beter.

Als ik op http://en.wikipedia.org/w...rtcomings_of_OpenDocument kijk naar de pluspunten en tekortkomingen van ODF en OOXML dan lijkt OOXML beter, vooral punt 1 en 2 bij "Shortcomings of OpenDocument" lijken mij redelijk ernstig.

WP-Office en OpenOffice zijn zo'n beetje de enige suites met een beetje serieus marktaandeel, om dat nou te omschrijven als "All major Office suites" is een beetje tendentieus.

@Maurits:
MS is bij de certificeren van ODF1.0 niet dwars gaan liggen. Het zou me niets verbazen als MS en partners de certificieren van ODF1.2 zullen (proberen te) blokkeren zolang de ODF-aanhangers OOXML tegenhouden. En dan zitten we met de 1 standaard die incompleet/verouderd is en 2 nieuwe standaarden die elkaar geen certificering gunnen.

[Reactie gewijzigd door SirBlade op 22 juli 2024 15:13]

[YaPP]

Als ik op http://en.wikipedia.org/w...rtcomings_of_OpenDocument kijk naar de pluspunten en tekortkomingen van ODF en OOXML dan lijkt OOXML beter, vooral punt 1 en 2 bij "Shortcomings of OpenDocument" lijken mij redelijk ernstig.

Er ontbreken inderdaad nog grote zaken in ODF:
- macro formules
- tabellen in presentaties
- password encryptie.
- digitale handtekening.

De punten lijken in vergelijking met OOXML inderdaad groter, maar zijn dat niet. Wat er nu in de specificatie zit is goed uitgewerkt. Wat nog niet goed genoeg was wordt eerst verder over nagedacht, met experts uit de verschillende disciplines.

OOXML draait het om: eerst alles (deels) ondersteunen, daarna kijken wat er te herstellen is. Volledige functionaliteit die ontbreekt lijkt erger dan percentages die inconsequent zijn, of datum/tijd functies die niet voor 1990 fouten geven. Het maakt straks echter wel verschil voor de boekhouder of wetenschapper die verwacht dat formules goed werken.

[Reactie gewijzigd door YaPP op 22 juli 2024 15:13]

[kidde]

[quote]Als ik op http://en.wikipedia.org/w...rtcomings_of_OpenDocument kijk naar de pluspunten en tekortkomingen van ODF en OOXML dan lijkt OOXML beter[quote]

Als het daarop aankomt, zou ik niet op Wikipedia vertrouwen, daar is een beetje een fanboy-oorlog (van weerszijden) aan de gang. Check wie hem ge-edit hebben, en je komt 'bekenden' tegen.

Tekortkoming 2, geen formula, en 4 zullen zijn verholpen in ODF 1.2.

Voor tekortkomingen van OOXML kan je mijns inziens beter kijken op Grokdoc: http://www.grokdoc.net/index.php/EOOXML_objections . Een partijdige site, misschien wel van fanboys, maar alle stellingen/feiten daar zijn te controloren, en er zijn geen edit-wars daar.

[Maurits van Baerle]

Deze post op het ARS forum geeft wel een aardig beginnetje met wat er mist of kapot is in OOXML.

Overigens zijn toevallig al die vier ODF tekortkomingen uit dat lijstje inmiddels gefixt voor ODF 1.2. Er zullen vast nog wel zaken verbeterd kunnen worden aan ODF maar het zijn eigenlijk nooit regelrechte bugs zoals die in OOXML regelmatig worden ontdekt.

[Reactie gewijzigd door Maurits van Baerle op 22 juli 2024 15:13]

[Verwijderd]

Overigens zijn toevallig al die vier ODF tekortkomingen uit dat lijstje inmiddels gefixt voor ODF 1.2.

Er is nog steeds geen officiele OASIS ODF versie 1.2 ruim twee jaar na de standaardisatie van versie 1.0 en het is nog steeds onduidelijk wanneer die er nou eindelijk komt. Deze 1.2 versie zou namelijk al opgeleverd moeten zijn maar dat is nog steeds niet gebeurd en en een definitieve gestandaardiseerde OASIS versie zal mogelijk dit jaar ook niet gebeuren laat staan een versie die door ISO is goedgekeurd.

Verder is het zo dat ODF blijkbaar met bepaalde tekortkomingen ook door de ISO standaardisatie is gekomen en ook OOXML kan bij standaardisatie nog wel tekortkomeningen hebben die in een latere versie worden verholpen.

[Maurits van Baerle]

Pardon? ODF 1.2 stond gepland voor eind dit jaar maar de planning is vervroegd omdat een aantal zaken soepeler gingen dan verwacht. Het hele formule gedeelte werd bijvoorbeeld pas rond de zomer verwacht maar bleek uiteindelijk al in februari klaar.
OASIS goedkeuring zal dit jaar dus ook wel plaatsvinden, ISO zal wel langer duren inderdaad en verwacht ik op z'n vroegst begin volgend jaar.

Verder zitten er inderdaad tekortkomingen in ODF 1.1, maar dat zijn ontbrekende zaken, geen regelrechte bugs. Het is makkelijker om later ontbrekende onderdelen toe te voegen dan bijvoorbeeld twee incompatible datum-formaten in één standaard(!) te vervangen door ISO8601 zonder vervelende backward compatibility issues te krijgen.

[Verwijderd]

Pardon? ODF 1.2 stond gepland voor eind dit jaar maar de planning is vervroegd omdat een aantal zaken soepeler gingen dan verwacht. Het hele formule gedeelte werd bijvoorbeeld pas rond de zomer verwacht maar bleek uiteindelijk al in februari klaar.

Sorry ? Formula's klaar in Februari ???
Waar staat dan de officiele OpenFormula standaard ?
Ik heb nog nergens een door OASIS gestandaardiseerde versie van de formula's gezien.
Alleen maar drafts
Dit is de meeste recente draft versie van 20 juni:
http://www.oasis-open.org...&wg_abbrev=office-formula
Beetje vreemd om 4 maanden nadat het in februari klaar zou zijn in juni nog met een draft versie te komen.
En als er nu nog slechts drafts zijn van Openformula dan lijkt me dat v1.2 ook niet verder is dan dat stadium.

[YaPP]

Op welke vlakken is OOXML inferieur aan ODF? Zaken als "setSpacesLikeWord95" zullen duidelijker verwoord moeten worden maar dat maakt ODF op zich niet beter.

Excel formules zijn bijzonder overhaast uitgewerkt (interessante toelichting). Waarden van basisfuncties verschillen dusdanig van eenheden dat ze niet te combineren zijn. Dat geld al voor simpele functies als sin() en cos(). Het is zo inconsequent dat er voor andere functies gegarandeerd rekenfouten ontstaan; met name als een ander office pakket het OOXML bestand bewerkt en opslaat. Je kunt dus niet vertrouwen op een ooxml boekhouding als die met een ander pakket geopend is. ODF is al een tijd bezig met formules, dat duurt alleen langer omdat ze ook peer-reviews krijgen door experts (wiskundigen en wetenschappers). De betrouwbaarheid zal wel groter zijn daardoor.

Datum en tijds functies moeten allemaal rekening houden met Excel bugs uit het verleden. Dat maakt OOXML niet compatible met onze standaard kalender of datumvelden uit andere bestanden.

OOXML maakt gebruik van standaarden die niet slecht gedocumenteerd zijn, of gesloten zijn. Denk aan WMF en RTF. Vectortekeningen worden opgeslagen in VML, wat nergens waar niet alles van bekend is.

Hoe meer je leest over OOXML, hoe meer het op een eenrichtingsweg lijkt van OpenOffice naar MS-Office. het artikel Microsoft on standards geeft een aardig beeld van Microsoft's strategie. Het is ook niet de eerste keer dat Microsoft hiermee bezig is. Office 97 had documentatie om de binaire bestanden uit te lezen. Office 200, XP en 2003 hadden ook al een XML formaat. Al deze formaten zijn bij een nieuwe versie van Office overboord gegooid. Van al deze pogingen is ook achteraf bekend dat ze bedoeld waren de monopoly positie van Office te vergroten i.p.v. "open" te zijn. (bron)

[Reactie gewijzigd door YaPP op 22 juli 2024 15:13]

[Verwijderd]

OOXML maakt gebruik van standaarden die niet gedocumenteerd zijn. Zo worden vectortekeningen opgeslagen in VML, wat nergens bekend is.

Verzin je dat nou zelf ?
De gehele VML spec is al 10 jaar geleden volledig gepubliceerd toen Microsoft deze heeft voorgedragen voor opname bij W3C. De VML spec staat ook nog als draft spec op de W3C site. Verder heeft Microsoft de VML opgenomen in OOXML en is juist een door velen gevraagde optie om de VML spec uit de OOXML format beschrijven te halen en alleen ter referentie in een annex te zetten.

[YaPP]

http://www.robweir.com/bl...rosoft-on-standards.html:

VML is a proprietary standard, which has been more or less documented in OOXML, but whose rendering is full of semantics and technical details that are left for one to discover. If you intend to reproduce a VML stack, budget for a good year of work at least.

What's bad when it comes to VML? Well, certainly that never are there been more VML based parts in Microsoft formats than in OOXML.

VML is nooit verder gekomen dan een draft specificatie. Niet anders dan OOXML nu. Het W3C heeft de keus laten vallen op SVG i.p.v. VML. Kun je ook met zekerheid zeggen dat de VML in OOXML nu hetzelfde is als hetgeen wat als draft in 1998 gepubliceerd is?

[Reactie gewijzigd door YaPP op 22 juli 2024 15:13]

[Verwijderd]

Kun je ook met zekerheid zeggen dat de VML in OOXML nu hetzelfde is als hetgeen wat als draft in 1998 gepubliceerd is?

Aan gezien er 600 pagina's VML specificatie zitten bij OOXML lijkt het me vrij zinloos om daar nog de moeite voor te nemen. Echter je zei dat VML niet gedocumenteerd is en nu neem je dat al terug door een quote aan te halen waarin staat dat het meer of minder is gedocumenteerd.

Aan de andere kant, in ODF gebruiken ze zogezegd SVG maar omdat SVG niet de 3D functionaliteit uit OpenOffice ondersteunde hebben ze in OOXML een propriety uitbreidingen gedaan van SVG voor onder meer 3D functionaliteit die nog veel minder beschreven zijn als VML in OOXML. Zo is het volstrekt onduidelijk of je in ODF traditionele SVG kan mixen met de propriety 3D draw commando's en daarmee de compatibiliteit met SVG in ODF niet gewaarborgd is. Dat staat namelijk niet beschreven in ODF. Verder gebruikt ODF draw objects om bijvoorbeeld java te embedden. Ook niet echt standaard SVG drawing features eigenlijk en waarom gebruiken ze daar niet gewoon de w3c xlink standaard voor die wel op andere plaatsen in ODf gebruikt word om bijvoorbeeld media files in presentaties te embedden.

Oh ja, er ook ook nog geen enkele corrente implementatie van alle drawing elementen in ODF pas twee jaar na standaardisatie en ondanks dat de features deels rechtreeks onleend zijn aan OOo.

[Verwijderd]

Op welke vlakken is OOXML inferieur aan ODF? Zaken als "setSpacesLikeWord95" zullen duidelijker verwoord moeten worden maar dat maakt ODF op zich niet beter.

Als je moet beschikken over de proprietary code van word95 of word97 om iets te implementeren lijkt het me duidelijk dat de standaard niet open is.

Een aantal dingen die mis zijn vallen hier te lezen (er zijn er vast meer) :
http://www.noooxml.org/petition
http://www.robweir.com/blog/2007/07/formula-for-failure.html
http://www.fsfe.org/fello.../ms_ooxml_conversion_hoax
http://www.fsfe.org/fello...uirer_on_ms_ooxml_and_odf

Bovendien lijkt het met stug dat MS de volgende vragen kan beantwoorden tot ieders tevredenheid :
http://fsfeurope.org/documents/msooxml-questions

[mashell]

already implemented by all major office suites (except by MS Office).

Haha. Er is maar 1 major office suite en dat is MS Office. De rest opereert in de marge. En hoe erg zou het zijn dat de Open Office auto spaces worden toegepast waar die van word95 bedoeld zijn? Als de opmaak behouden moet blijven maak je een PDF (ik weet, vloeken in de open standaard kerk) maar het gaat er om bij die open standaarden dat de informatie bruikbaar blijft en daar doet een niet helemaal compatible Word97 Line Breaks Rules implementatie niets aan af.

[psyBSD]

tja... maar als ik dat zou willen implementeren moet ik wel Word97 zien te krijgen (waar haal je die nu nog legaal), installeren (op welk systeem werkt dat nu nog) en proberen te achterhalen wat microsoft hier nu precies mee bedoelt.

Stel dat blijkt dat dit compatibility met een bug is, dan wordt het helemaal lastig. Er moet een implementatie komen die zowel 'correct' functioneert en moet voldoen aan de 'Word97-methode', niemand die aan de specs kan zien of dat zelfs mogelijk is.

Dezelfde procedure moet ook worden doorlopen met word95, ik denk niet dat ik hoef uit te leggen dat dit practisch onmogelijk is. We hebben het hier over twee software-pakketten van respectievelijk 10 en 12 jaar oud, die moesten draaien op een platform dat jarenlang elke poging van standarisatie heeft ontweken.

Kortom, het implementeren van OpenXML is... tja... niet mogelijk.

[Verwijderd]

Er is helemaal geen reden om dat te implementeren.
Een dergelijk compatiblity item geeft namelijk aan dat iets afwijkt van iets wat je ook al niet hebt geimplementeerd.
Het enige nut van een dergelijk compatibility item is dat je een gebruiker kan informeren dat je voor originele rendering van het document bij een oude legacy applicatie moet zijn. Ook kan je dergelijk bestanden makklijk identificeren in een geautomatiseerde conversie en deze bestanden dan aanvullend visueel controleren om te zien.
Rendering van Office documenten is echter niet beschreven in de spec (ook niet in ODF) en rendering is dus implementatie afhankelijk en zo dus ook afwijkende rendering. De enige die een document gemaakt in MS Office 100% identiek kan renderen is MS Office maar de enige die een document gemaakt in OpenOffice identiek kan renderen is OpenOffice. Dat is ongeacht welke format spec je gebruikt.

[Verwijderd]

Je hebt gelijk dat er geen reden is om te verwijzen naar een implementatie,

Dat zie je verkeerd (en zeg ik ook helemaal nergens).
Er is juist wel reden om te verwijzen naar een implementatie.
Zo is het bijvoorbeeld mogelijk om bij een conversie mogelijk verminkte bestanden te identificeren en te zien dat het je het origineel alleen met een bepaalde implementatie goed kan bekijken.

Verder mag jij uitleggen hoe je bij een document gemaakt in OpenOfffice bijvoorbeeld in KOffice identieke rendering wil gaan realiseren puur op basis van de ODF spec.
Dat is namelijk volstrekt onmogelijk omdat dit niet door de ODF spec wordt beschreven maar blijkbaar vindt men dat bij het beoordelen van een OOXML formaat ineens een belangrijke feature voor geconverteerde legacy bestanden.

[psyBSD]

Dat zie je verkeerd (en zeg ik ook helemaal nergens).
Er is juist wel reden om te verwijzen naar een implementatie.
Zo is het bijvoorbeeld mogelijk om bij een conversie mogelijk verminkte bestanden te identificeren en te zien dat het je het origineel alleen met een bepaalde implementatie goed kan bekijken.

Mss heb je gelijk, daarentegen:

Conversie is irrelevant, als de conversie van oude proprietaire formaten van belang is voor de correcte implementatie van een open standaard. Dan kan is die standaard toch niet echt 'open' (en/of dus vrij te implementeren)?! Je moet immers gaan reverse-engineeren om te voldoen aan de specs.

Verder mag jij uitleggen hoe je bij een document gemaakt in OpenOfffice bijvoorbeeld in KOffice identieke rendering wil gaan realiseren puur op basis van de ODF spec.
Dat is namelijk volstrekt onmogelijk omdat dit niet door de ODF spec wordt beschreven maar blijkbaar vindt men dat bij het beoordelen van een OOXML formaat ineens een belangrijke feature voor geconverteerde legacy bestanden.

Dit is voor zover ik weet ook een reden dat MS zich afzijdig heeft gehouden / op een zijspoor is gezet (laat ik even in het midden, dit weet ik niet zeker) bij de ontwikkeling van ODF. Zij wilden backwards-compatibility met hun eigen producten ( bugs) in de standaard onderbrengen. Iets wat de andere participanten niet wilden.

Wat betreft renders, daarin geef ik je gelijk, dit kan je niet garanderen. Maar dit is nooit het geval geweest bij office-suites. Zelfs niet als je ze allemaal uit dezelfde stal haalt, MS-Office 97/2000/XP/2003, ze renderen de documenten gemaakt door hun voorganger(s) allemaal anders (of niet). Om het makkelijk te maken .

[Verwijderd]

Wat betreft renders, daarin geef ik je gelijk, dit kan je niet garanderen.

Toch is het juist daarover dat je een punt maakt. Tegenstanderss van Micrsoft eisen bij bepaalde legacy compatibility tags een soort definitie hoe ze die moeten renderen terwijl in office standaards daar voor huidige versies niets wordt gedefinieerd.

Conversie is irrelevant, als de conversie van oude proprietaire formaten van belang is voor de correcte implementatie van een open standaard. Dan kan is die standaard toch niet echt 'open' (en/of dus vrij te implementeren)?! Je moet immers gaan reverse-engineeren om te voldoen aan de specs

Je moet helemaal niks. Alle delen van OOXML zijn optioneel. Als je geen legacy tags wilt ondersteunen omdat je ze toch niet kan renderen dan die je dat niet. Echter Microsoft die wel blijoenen legacy documenten bij klanten heeft staan will waarschijnlijk wel een hoog niveua van converise betrouwbaarheid bieden. Dat kan dus met het OOXML formaat. Anderen die niet die hoge mate cvan conversiebetroubaarheid willen voor legacy documenten kunnen OOXML ook gebruike.
Als Microsoft een standaard had aangeleverd zonder compatiblity tags daarin gedefnieerd maar daarnaast in geconverteerde documenten allenmaal ongedocumenteerde uitbreidingen had gestopt om legacy compatibiliteti te ondersteunen (zoals OOo) haddden de tegenstanders van OOXML daarover geklaagd dat Microsoft essentiele conversie informatie in propriety extensies had verborgen.
Ofwel met dergelijke oppositie kun je het nooit goed doen.

[kidde]

Tegenstanderss van Micrsoft eisen bij bepaalde legacy compatibility tags een soort definitie hoe ze die moeten renderen

Aha, dus mensen die graag Microsoft OOXML op een fatsoenlijke manier in hun software willen implementeren zijn tegenstanders van Microsoft? Ik weet voor de volle 100% zeker dat de afdeling 'Evangelisme' van Microsoft hier anders over denkt, en dat ze zeker niet blij zullen zijn met zulke statements.
Immers, de belangen van MS OOXML als platform hebben voorrang op de belangen van winst op Microsoft Office. Microsoft denkt er als volgt over: Een nadeel aan "open" formaten is dat 'concurrenten' hem ook kunnen implementeren, maar het voordeel hier is dat Microsoft altijd als eerste en de beste OOXML ondersteuning zal hebben (bijna letterlijk gequote uit de strikt vertrouwelijke dia-presentatie die de afdeling Microsoft evangelisme toonde, en die recent in de Ohio-antitrust-horingen publiek werden).

[Verwijderd]

Aha, dus mensen die graag Microsoft OOXML op een fatsoenlijke manier in hun software willen implementeren zijn tegenstanders van Microsoft?

Nee hoor.
Echter aangezien een exacte beschrijving van de rendering van zowel ODF als OOXML geen onderdeel uit maakt van beide formaten is het onzinnig om dit wel appart te verwachten voor legacy compatibility.

Stel nou eens dat Microsoft bij een bepaalde setting als
setSpacesLikeWord95
toevoegt dat bij deze setting spaties aan het eind van een regel op het scherm 1 pixel minder groot zijn dan op andere plaatsen.
Dat is het misschien corerct beschreven maar je hebt er niks aan omdat dergelijke office standaarden niet beschrijven hoe je een regel moet renderen en dus kan in iedere implementatie van OOXML of ODF een regel anders getoond worden bijvoorbeeld doordat ze op een andere plaats worden afgebroken.

Het is dus een onterechte veronderstelling dat het toevoegen van deze informatie het mogelijk maakt om een document identiek te renderen. Het is zelfs mogelijk dat latere MS Offfice versies dat niet meer goed kunnen.
Aangezien renderingkeuzes geen onderdeel zijn van dergelijk Office standaard formaten heeft het op een fatsoenlijke manier in software implementeren daar dus ook niks mee te maken. Er zijn nu ook geen twee implementaties van ODF die identiek documenten renderen en het zou dus belachelijk zijn om te denken dat je dat wel kun bereiken met legacy documenten uit een andere applicatie. Dat is gewoon lachwekkend.

[Verwijderd]

Ga ergens anders trollen als je je verveelt. Er zit geen enkele spelfout in trouwens.

[psyBSD]

Hmm, de kwaliteit van de OpenXML specificatie moet wel echt onder de maat zijn als het zelfs door de Amerikaanse ISO-leden wordt tegengehouden. Microsoft is een Amerikaans bedrijf, en het is voor de Amerikaanse economie interessant als amerikaanse bedrijven internationaal goed scoren. Een internationaal monopolie is dan natuurlijk ideaal.

Ik had daarom ook eigenlijk verwacht dat de weerstand tegen OpenXML vooral vanuit de rest van de wereld moest komen. Nu zelfs in Amerika geen meerderheid is voor de standarisatie van de OpenXML spec krijg ik het idee dat het inderdaad (zoals door grokdoc wordt aangegeven) een document-formaat is die we beter links kunnen laten liggen.

[Verwijderd]

Hmm, de kwaliteit van de OpenXML specificatie moet wel echt onder de maat zijn als het zelfs door de Amerikaanse ISO-leden wordt tegengehouden.

14 voorstemmer en 9 tegenstemmers (een twee derde meerderheid is noodzakelijk)
De tegenstemmen zijn onder andere van Microsoft concurrenten IBM, Sun, redhat en Oracle.

[psyBSD]

... Zoals gewoonlijk bij dit soort processen moet ieder betrokken land vervolgens zijn goed- dan wel afkeuring uitspreken. In het geval van Amerika is afgelopen vrijdag gestemd over het ooxml-voorstel en bleek dat er van de 26 leden 10 voor- en 15 tegenstemden; het laatste lid onthield zich van stemming.

Deze cijfers komen uit het nieuws-bericht, nu moet ik toegeven dat ik die niet direct terug vind in de bron. Ik zou graag willen weten waar je de 14 voor- en 9 tegenstemmen vandaan haalt.

Ik vind het interessant om te zien dat een standaard die tot stand is gekomen uit samenwerking tussen de grootste software ontwikkelaars ter wereld, in overleg met mensen die het ook daadwerkelijk zouden gaan gebruiken, zonder problemen aan de kant dreigt te worden gezet omdat Microsoft zijn eigen in-house ontwikkelde documentje wil standariseren. Iets wat ze pas zijn gaan ontwikkelen nadat er een officiele standaard is gekomen die dreigt hun monopolie op de office-markt te doorbreken.

Als MS gewoon mee zou doen met de rest van de software wereld is er niets aan de hand, alle documenten zijn onderling uitwisselbaar en gebruikers kunnen zaken doen met wie ze maar willen. Maarja, dan hebben we een vrije markt... en dat willen we natuurlijk niet.

[Verwijderd]

Ik zou graag willen weten waar je de 14 voor- en 9 tegenstemmen vandaan haalt

Sorry, het was eigenlijk 15 voor en 10 tegen. Mijn geheugen is slecht.

Roll-Call Vote #1:
Motion: Lynn/Scott that the recommendation on the U.S. position on DIS 29500 be “Approval with comments”.
Roll-Call Vote on “Approval with Comments”
Voting Member
Vote
3Sharp YES
Advaiya YES
Blackbird Tech YES
BP YES
Document Sciences YES
Farance Inc. NO
IBM NO
Ligent NO
Microsoft YES
Mimosa Systems YES
Mindjet YES
NextPage YES
Oracle NO
Peters & Associates YES
Reality Mobile YES
Red Hat NO
Retrieval Systems Corp. NO
Revonet YES
Snowfall Software NO
Sun Microsystems NO
Text Structure Consulting NO
US DoD/DISA ABSTAIN
Washington State Archives YES
Xinnovation YES
Z5 Technologies YES
Y-12 National Security NO
Result: 15-10-1-0-26. This meets the majority requirement (simple majority of 26 = 14), but fails the 2/3 rule (15/25 [with 1 abstention discarded] is 60.00%, which is less than 66.67%.).

Veel van de voorstemmers hebben of aan de spec gewerkt in Ecma of zijn bedrijven die oplossingen bieden rondom Microsoft Office. De tegenstanders zijn over het algemeen concurrenten van Microsoft of zijn/waren betrokken bij OpenDocument.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 15:13]

[hansg]

De voorstemmers daarentegen zijn vooral allerlei vage bedrijfjes die "toevallig" pas heel recent bij de commissie zijn gekomen...

[intGod]

Als ik het goed lees is de workaround voor MS dus:

Bundel de software met een ODF plugin. Verkoop aan overheden. Overheden zullen toch automatisch OOXML gaan gebruiken omdat dat in praktijk de meest voorkomende variant zal zijn.

Een programmeur had het niet beter kunnen bedenken

[PolarBear]

Ja en de certificering dan?

[cariolive23]

Die is er dankzij ODF. Dat ODF door de gebruikers vervolgens links wordt gelaten, daar kan MS niets aan doen. Het zal MS echter geen slapeloze nachten bezorgen .

[servies]

Blijkbaar heb je het niet begrepen. Het is niet aan de gebruikers om te bepalen wat voor formaat ze gebruiken, dat wordt door de desbetreffende organisatie opgelegd. En de reden voor het gaan gebruiken van een open standaard die op ELK platform bruikbaar is mag duidelijk zijn....

[cariolive23]

Tuurlijk, de organisatie bepaalt dat... Er zit echter een verschil tussen de theorie en de praktijk.

[Little Penguin]

Tuurlijk, de organisatie bepaalt dat...

Dat bedrijven met binaire MS-Office formaten zulllen blijven werken dat is, zeker op de korte termijn, te verwachten - bij veel bedrijven geldt nu eenmaal dat het niet uitmaakt of iets goed te archiveren is. Vaak is het woord Microsoft voldoende om bedrijven over te halen iets te gebruiken...

Als overheden echter gaan eisen dat er een ISO-standaard gebruikt moet worden en daar voor, naast een office suite, ook andere toepassingen in gebruik gaat nemen zullen overheden wel degelijk over gaan stappen.

Als scholen e.d. dan ook over zullen gaan, opnieuw is dat inderdaad niet iets waar je van kan zeggen dat zoiets direct zal gebeuren, dan zal de bekendheid en acceptatie van het ODF-formaat met sprongen toe gaan nemen.

Er zit echter een verschil tussen de theorie en de praktijk.

Het verschil wordt dus vooral bepaald door het soort organisatie.

Waar sommige bedrijven misschien wel veel praten over goed archiveren is de keuze voor binaire officeformaten of formaten (zoals ooxml) die verwijzen naar andere binaire formaten of gesloten informatie van closed-source applicaties een garantie dat het archief op termijn onleesbaar zal zijn....

[psyBSD]

Eerlijke concurentie, met het daarbij komende voordeel dat producten kunnen worden beoordeeld op prijs en kwaliteit. Niet enkel de redenatie: 'we hebben dit, en iets anders nemen is te duur'.

Je kunt dan serieus gaan kijken naar een andere leverancier wanneer A zijn werk niet goed doet. Want de migratie-kosten (en risico's) kunnen worden gedecimeerd.

[YaPP]

Bundel de software met een ODF plugin. Verkoop aan overheden. Overheden zullen toch automatisch OOXML gaan gebruiken omdat dat in praktijk de meest voorkomende variant zal zijn.

Nog erger.. de huidige add-in doet niet veel meer dan een ODF document omzetten naar een tijdelijk OOXML bestand, en die dan inlezen. Bij het opslaan of Ctrl+S wordt het document weer als OOXML opgeslagen. Je moet zelf door het menu, ODF, Opslaan als om het weer in ODF te krijgen. Het is ook niet mogelijk om een ODF document van scratch te maken, je moet het eerst opslaan als OOXML.

Gebruikers zullen hierdoor ODF maar lastig vinden, en mooi bij Microsoft's bestanden blijven. Het "OOXML compatibility pack" van Microsoft heeft deze beperkingen echter niet, het kan dus wel! (bron).

Het valt min of meer onder pesten, maar ondertussen zorgt dit er wel voor dat Microsoft voor elkaar krijgt wat ze willen. Een open formaat wat op ieder office pakket werkt helpt het monopolie van Office onderuit, en daarmee een van de hoekstenen van Windows. Zo'n ODF plugin maakt de overheid blij over ODF ondersteuning, terwijl het ondertussen alles naar OOXML overzet.

[Reactie gewijzigd door YaPP op 22 juli 2024 15:13]

[Verwijderd]

Het "OOXML compatibility pack" van Microsoft heeft deze beperkingen echter niet, het kan dus wel! (bron).

Het OOXML compatibility pack is een gestripte versie van de MS Office 2007 engine. Dat is dus niet zo maar eventje een plugin maar een zwaar gestripte versie van een major applicatie. Een plugin bouwen voor ODF kan dus wel maar is extreem last. Sterker nog, er is na twee jaar nog geen enkele gewone office applicatie die alle ODF features heeft ingebouwd. Laat staan dat je dat dus snel in een plugin kan bouwen. Een plugin bouwen voor heel ODF is dus iets wat nog jaren kan duren

[kidde]

Ach, Microsoft Office 2007 kan ook niet eens in de OOXMLstandaard die nu bij de ISO ligt opslaan: "no application exists that is a reference implementation for the formats Ecma TC45 has submitted to ISO". (bron)

Het is wel erg slecht voor een bedrijf die aan ECMA vraagt een standaard bij een bestaand bestandsformaat te schrijven, dat haar eigen office-product deze standaard niet eens ondersteund, en alleen mensen met een IQ lager dan hun leeftijd zullen niet begrijpen dat dit bedoeld is om te zorgen dat de bestandsformaten geproduceerd door Office 2007 zo incompatibel mogelijk zullen zijn ("in the Office Open XML draft standard, Microsoft disclosed only a crippled subset of the markup and functionality of its new file formats"), dus bedoeld om de vendor - lockin te behouden, en de data van de gebruikers blijvend te 'gijzelen' (on- / slecht toegankelijk zonder Microsoft software te houden).

[Reactie gewijzigd door kidde op 22 juli 2024 15:13]

[Verwijderd]

MS Office 2007 is misschien geen perfecte implementatie van OOXML maar implementeert zo te zien meer features van OOXML dan alle implementaties van ODF bij elkaar doen van ODF terwijl deze al jaren langer bezig zouden zijn.

Ik mis trouwens in je brontekst wat er nou precies niet gesaved kan worden in OOXML . Ik schrijf hier regelmatig bestandjes weg in MS Office 2007 en zo te zien voldoen die toch behoorlijk goed aan de OOXML spec.

Bovendien ken ik Marbux zijn tekstjes nou wel. Die wist nog niet eens wat patent claims waren toe hij op groklaw een stuk ging schrijven over het OOXML covenant not to sue.

[Maurits van Baerle]

Ik ben eigenlijk voornamelijk bang dat die plugin bewust matig compatible zal worden gemaakt zodat vertaalfouten onvermijdelijk zijn en het net lijkt of ODF bepaalde zaken niet of slecht ondersteund.

De door MS gesponsorde Open Source vertaal plugin lijdt ook nogal onder designfouten waarvan je bijna zou denken dat ze bewust zijn gemaakt.

[Verwijderd]

Standaarden zijn geweldig, iedereen zou er eentje moeten hebben

[maxxware]

Maar het is MS er natuurlijk om te doen dat iedereen er eentje van Microsoft gebruikt. En dan het liefst een gepatenteerde, want dan kan MS er geld voor vragen. En slecht beschreven natuurlijk, want het is wel de bedoeling dat alleen MS software goed overweg kan met die 'standaard'.

[Typos ge-edit]

[Reactie gewijzigd door maxxware op 22 juli 2024 15:13]

[Verwijderd]

Alleen jammer dat er in die 6000 pagina's ook nog verwezen wordt naar documenten van Microsoft, die niet voor het publiek toegankelijk zijn...

Noem eens zo'n document ?