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 , , 102 reacties
Bron: ZDnet

Microsoft heeft een open brief aan IBM geschreven, waarin het verzet van Big Blue tegen standaardisering van Office Open XML wordt gekapitteld. IBM beperkt de consument in zijn keuze, zo vindt de softwarebouwer uit Redmond.

Microsofts Jean Paoli (rechts) geeft ooxml-standaard aan Ecma's Jan van den Beld Microsoft is momenteel bezig om iso-certificatie voor zijn ooxml-formaat te regelen, maar dat gaat niet zonder problemen. Omdat het bestandsformaat van het bedrijf een Europese standaard is - de Ecma ratificeerde ooxml jongstleden december - mocht Microsoft een versnelde procedure voor het iso-label doorlopen. Meer dan een derde van de bij de International Organization for Standardization aangesloten landen heeft al kleine en grote bezwaren tegen het nieuwe Office-bestandsformaat ingebracht - veel meer dan bij andere aanvragen gebruikelijk is.

IBM logoDe verantwoordelijkheid voor het verzet tegen ooxml ligt bij Big Blue, schrijft Microsoft: 'IBM heeft een wereldwijde campagne opgezet om overheden te overtuigen dat ze ooxml links moeten laten liggen. Office Open XML heeft een heel andere doelgroep dan het door IBM gesteunde Open Document Format, maar IBM vindt één standaard kennelijk wel genoeg.' Microsoft wijst er in de brief op dat IBM ook al de enige organisatie was die bezwaar had tegen het verlenen van het ecma-keurmerk aan het Office-bestandsformaat, en trekt vervolgens alle registers open: 'Het bedrijf probeert het standaardiseringsproces te misbruiken om keuzevrijheid in te perken, en uiteindelijk doen ze dat alleen maar om er geld aan te kunnen verdienen. IBM doet de vrije keuze ook nog eens geweld aan door te proberen om overheden het gebruik van odf te laten verplichten.'

Microsoft Office-logoMicrosoft is zich duidelijk bewust van het feit dat het eigen verleden in dit opzicht ook niet helemaal brandschoon is. Maar: 'Wij hebben naar onze klanten geluisterd, en onze klanten willen een keuze hebben.' Medeondertekenaar Tom Robertson, Microsofts algemeen manager voor interoperabiliteit en standaarden, laat er echter geen misverstand over bestaan wie ditmaal de kwaaie pier is: 'IBM is hypocriet bezig. Ze roepen al jaren dat we onze bestandsformaten moeten standaardiseren en dat we de achterliggende technologie voor de gemeenschap beschikbaar moeten maken, en dat hebben we gedaan - en nou proberen ze met een goed voorbereide campagne het hele bestandsformaat uit de markt te drukken. 'IBM is fundamentally on the wrong side of the industry.

Lees meer over

Gerelateerde content

Alle gerelateerde content (30)
Moderatie-faq Wijzig weergave

Reacties (102)

" IBM beperkt de consument in zijn keuze, zo vindt de softwarebouwer uit Redmond."

En ondertussen het binaire .doc-formaat al jaaaaren angstvallig gesloten houden.

Iets met pot en ketel en zwart zien enzo.
Er is een verschil tussen angstvallig geheim houden en niet publiceren. Het publiceren zelf zou al een probleem vormen voor microsoft, die er zelf amper nog aan uitgeraakt als je naar de convertieproblemen kijkt wanneer je een oud, iets ingewikkelder .doc bestand van een office 97 probeert te openen in een recente versie...

Persoonlijk vind ik dit idioot van microsoft, de consument vraagt helemaal geen 2 verschillende documentformaten, net zoals de consument ook niet vraagt 2 verschillende video-schijfjes te kunnen kopen (blue-ray & hd-tv). Men probeert hier gewoon hetzelfde te doen als in het high-definition video gebeuren, namelijk een format-war winnen. Waarom? Omdat hoewel het ooxml formaat 'open' is, er toch windows specifieke zaken inzitten als ole-object dingen die heel moeilijk te porten zijn naar andere platforms, en zij dan de touwtjes in handen hebben.

Het enige wat de consument wel vraagt is een formaat dat ze overal kunnen lezen, en voor business-klanten iets waar ze zelf makkelijk in kunnen werken vanuit eigen applicaties. 2 formaten zou de boel enkel ingewikkelder maken...
Laat ooXML nu net de opvolger van het doc formaat zijn. Ook
Microsoft is zich duidelijk bewust van het feit dat het eigen verleden in dit opzicht ook niet helemaal brandschoon is.
Microsoft trekt blijkbaar lering uit het verleden, waarom dan blijven klagen dat ze iets fout gedaan hebben?
Misschien wel omdat de 'nieuwe open' standaard allerlei verwijzingen en afhankelijkheden blijkt te hebben naar MS-specifieke zaken? Als daar bijvoorbeeld voorzieningen in zitten om oude DOC bestanden te gebruiken dan wordt het voor 3rd party ontwikkelaars zo goed als onmogelijk om deze 'open' standaard ook te implementeren. Ze hebben namelijk geen toegang tot de gegevens van het oude DOC formaat.
hoef je ook geen windows meta files te implementeren. Als je ze echter wel wilt implementeren dan biedt OOXML een apart filetype identificatie ervoor
Dat maak ik me bezorgd om, aangezien MS Office dit zeker zal implementeren, zullen andere softwarepakketten die dit niet implementeren dit zien als niet standard-compatiblezijn van die andere softwarepakketten. Als geval hiervan hoeft het theoretisch niet, maar praktisch is het problemen over jezelf afroepen om ze niet te implementeren.
Er is geen enkele eis in de spec dat er behaviour gecloned moet
Zie boven: Niet geeist, maar gebruikers zullen zeker klagen als het niet geimplementeerd is.
worden en het behaviour van die oude rendering wordt ook helemaal niet omschreven.
Door het niet omschrijven ervan moeten de oude formaten waar OOXML naar verwijst, gereverse-engineerd worden. Dat is illegaal volgens hun EULA, waardoor een conforme implementatie mogelijk ook illegaal zal zijn, indien geen licentiegeld aan de desbetreffende bedrijven wordt betaald.
Heb je daar ook nog een link van? Beweren is één ding, maar ik zou het graag zelf lezen.

Edit:
Interessant, tnx psyBSD
Triest dat het zogenaamde open wiki van Grokdoc gewoon gesloten pagina's zijn en geen commentaar wensen want daar op die objections pagina's staat namelijk gewoon voornamelijk pure onzin.

Zelfs al je volledig de OOXML standaard implementeert hoef je namelijk geen windows meta files te ondersteunen en hoef je geen ' behaviour te clonen' van oude Office versies. Dat staat gewoon niet in OOXML.

Het meta files issue:
Er staat inderdaad in OOXML een referentie naar te embedden filetypes als picture of de propriety windows metafile types. Maar net zoals dat je niet alle bestaande picture formaten hoeft te implementeren hoef je ook geen windows meta files te implementeren. Als je ze echter wel wilt implementeren dan biedt OOXML een apart filetype identificatie ervoor om ze te onderscheiden van normale filtypes (WMF zijn ook geen echte picture formaat files). Dat is dus eerder handig dan een requirement om metafiles te implementeren zoals op grokdoc wordt beweert.

Het cloning the behaviour van oude Office versies issue:
De OOXML spec bevatten een flink aantal tags die kunnen identificeren dat de originele versie van het document is gemaakt met een oude office versie en dat die afwijkende rendering gedrag vertoonde. Er is echter geen enkele eis dat dat gedrag door nieuwe applicaties wordt herhaald. Het is echter wel nuttig dat iemand kan zien dat het bestand er in huidige applicatie anders uitziet dan in de applicatie waarin het gemaakt is. Deze tags kunnen dus gebruikt worden om de gebruiker te informeren dat de filerendering is gewijzigd. Er is geen enkele eis in de spec dat er behaviour gecloned moet worden en het behaviour van die oude rendering wordt ook helemaal niet omschreven. Onzin dus.
Dat maak ik me bezorgd om, aangezien MS Office dit zeker zal implementeren, zullen andere softwarepakketten die dit niet implementeren dit zien als niet standard-compatiblezijn van die andere softwarepakketten. Als geval hiervan hoeft het theoretisch niet, maar praktisch is het problemen over jezelf afroepen om ze niet te implementeren.
Zowle OOXML als ODF laten toe dat je willekeurige bestanden embed. Daarop heeft het genoemde filetype geen invloed. MS Office kan dus WMF files ondersteunen ongeacht van deze feature in de OOXML specs. Het is echter onmogelijk dat je alle bestandtypes kan ondersteunen. Er zullen dus altijd bestandtypes embed worden in Office files die niet in andere office applicaties gebruikt kunnen worden.
En MS Office zal vermoedelijk altijd 1 van de meeste ondersteunende applicaties zijn gezien de grootte van het pakket. Het is echter met name voor non-windows applicaties handig om al in een vroeg stadium WMF files te herkennen omdat deze door de aard van dergelijke bestanden niet ondersteund worden op niet windows systemen. Een dergelijke filetype aanduiding is dus juist ook voor applicaties die niet windows georrienteerd zijn handig.
Waar het gewoon om gaat is dat het opnemen van een soort filetype door tegenstanders genoemd wordt als bezwaar tegen de spec omdat het zogenaamd een
'requirement' is om dat filetype te ondersteunen. Dat is dus onzin maar wordt niet gemeld. En bijvoorbeeld op Grokdoc mag ik die info er niet bij zetten. Dat vind ik opzettelijke misleiding.
" Er is geen enkele eis in de spec dat er behaviour gecloned moet"
Zie boven: Niet geeist, maar gebruikers zullen zeker klagen als het niet geimplementeerd is.
Aleereest ben je het dus eens dat het niet geeist wordt. dat maakt de beweringen van bijvoorbeeld de Grokdoc links al meteen onwaar. OOXML vereist dat niet.

Verder biedt een Office formaat je sowieso geen rendering informatie aan. Dat betekent dus dat bestanden in zowel ODF als OOXML er altijd in verschillende applicaties verschillend uit zullen zien. OOXML beschrijft geen rendering van Office 2007. Het zou toch gek zijn om dan bijvoorbeeld voor een oude ooit afwijkende versie dat wel te vermelden.

Ook bij ODF kamp je met dergelijke problemen.
Bijvoorbeeld in een OpenOffice bestand kan je een regel tegenkomen als:
<config:config-item config:name="AddParaTableSpacing" config:type="boolean">true</config:config-item>
Dat lijkt eeen meer standaard oplossing maar in feite is het config item een gestandaardiseerde manier om ongedefinieerd propriety behaviour in je ODF file te stoppen. In OOXML kun je bij het tegenkomen van een deprecated compatibility tag de gebruikers informeren over de aard van het afwijkend gedrag. Bij de ODF config items kun je dat niet omdat het niet duidelijk is wat ermee wordt bedoeld.

(p.s. de config:name en config:type ityem zijn OOo specifieke ODF extenties en dus ook niet in de spec gedefinieerd)
(p.s. de config:name en config:type ityem zijn OOo specifieke ODF extenties en dus ook niet in de spec gedefinieerd)
Dus jij valt het hele ODF kamp aan op basis van een extensie op de ODF-specificatie die alleen door een specifieke aanbieder wordt aangeboden?
t.t.t.t.

Overigens ga je niet in op hetgeen kidde zegt, of interpreteer je het anders dan ik:
als MS Office de embedded bestanden gewoon kan lezen EN weergeven, zullen klanten eisen dat bijvoorbeeld OO.o dat ook doet. Maar dat gaat niet, ivm licenties.
Met andere woorden: een deel van de functionaliteit van OOXML zal niet beschikbaar zijn voor andere ontwikkelaars.
Door te kiezen voor de MS standaard kies je impliciet voor elke andere standaard die MS in zijn besturingssyteem verwerkt heeft. Immers: MS OOXML zal alles wat aan niet-open standaarden in Windows zit gewoon kunnen weergeven, waar andere partijen dat niet kunnen in verband met licenties.
(En als je nu gaat zeggen dat dat met ODF ook kan: waarom dan een eigen standaard? Dan is ODF toch goed genoeg?)

In welke wereld is dat "Open"?
Overigens ga je niet in op hetgeen kidde zegt, of interpreteer je het anders dan ik:
als MS Office de embedded bestanden gewoon kan lezen EN weergeven, zullen klanten eisen dat bijvoorbeeld OO.o dat ook doet. Maar dat gaat niet, ivm licenties.
Je begrijpt gewoon geen woord van wat ik zeg .

Het gewoon een kwestie van implementatie en niet van de specificatie welke embedded filetypes worden ondersteund. Grotere applicaties zullen vermoedelijk betere directe ondersteuning leveren voor embedded files. Je kunt ook jepg, quicktime of flash files of PDF file embedden in Office files. Het embedden van WMF files is gewoon op geen enkele manier gerelateerd aan het implementeren de OOXML spec een suggestie die wel gewekt wordt door Grokdoc.

Ten slotte is het zo dat bijvoorbeeld OpenOffice op windows embedded WMF files gewoon al lang ondersteunt en dat je die files dus ook gewoon in ODF embedden.

Dus kort samengevat.
Als je OOXML implementeert is er geen reden om WMF ondersteuning te implementeren.
En als je WMF embedding ondersteuning wilt implementeren kun je dat zowel in OOXML als in ODF doen.
Volgens mij snappen we best wat je zegt, maar ga je niet op de de angst, onzekerheid en twijfel van mensen in over 'display as in Word95' specs en dergelijke in OOXML: Kan worden achterhaald hoe dat is, en kan dat worden gebruikt in open source software zonder een rechtzaak aan je broek te krijgen? (Zie Rob Weir's blog, waar je mee bekend bent)

Microsoft is een van de weinigen die dat zonder problemen kan doen, gezien het IP en de licenties daarop die ze hebben.

Als het slechts een kwestie van implementatie is, waarom staat de standaard er dan vredesnaam vol mee, en staat hen niet alleen in de implementatie (software, MS Office broncode dus) zelf?

Als het niet ondersteund hoeft te worden, laat het dan alsjeblieft weg, want zoals je ziet leidt het opnemen ervan in de standaard tot verwarring, onzekerheid, twijfel en angst, met name na de dreigementen die Microsoft tegen bepaalde groepen heeft geuit over dat men vroeg of laat de problemen zal ondervinden van inbreuk op Microsoft's IP.
'Display as in word 95', "date's like in MS Office xxx" en dat soort fratsen die herhaaldelijk opduiken in de OpenXML spec horen bij dat IP, en de implementatie ervan valt niet onder het 'convenant not to sue'. Laat zoiets weg uit de standaard, of geef het vrij en neem de hele specificatie van Word95 op in de standaard. Maar niet zeggen dat de implementatie een proprietary formaat nabootst in de standaard, want dan is de standaard effectief closed en niet meer open.
maar ga je niet op de de angst, onzekerheid en twijfel van mensen in over 'display as in Word95' specs en dergelijke in OOXML: Kan worden achterhaald hoe dat is, en kan dat worden gebruikt in open source software zonder een rechtzaak aan je broek te krijgen?
Je kun sowieso niet achterhalen hoe MS office OOXML files displayed. Dat is namelijk helemaal nergens vastgelegd. Je vraagt om het toevoegen van rendering informatie over oude office versies terwijl die informatie die niet eens is vastgelegd voor de MS Office 2007 versie. Rendering is altijd implementation specifiek
Als het niet ondersteund hoeft te worden, laat het dan alsjeblieft weg
Dat is niet slim want dan kun je niet meer herkennen dat een file voorheen anders gerenderd werd dan het huidige geconverteerde file en de gebruiker daarover informeren.

Waarom plaatst bijvoorbeeld Open Office anders allerlei propriety items als "AddParaTableSpacing", "UseOldNumbering", "UseFormerLineSpacing" in hun files. Dat is voor hun implementatie specifieke OpenOffice rendering.

Of vind je dat Openoffice daarmee ook angst, onzekerheid en twijfel bij mensen creeert ?
Microsoft trekt blijkbaar lering uit het verleden, waarom dan blijven klagen dat ze iets fout gedaan hebben?
Doordat Microsoft nog steeds bij bepaalde gedeeltes van hun ooxml terugvalt op 'zoals het werkt in Office 97'... wat niet open is.
ooxml is helemaal geen open standaard. Ze hebben bijvoorbeeld een aantal tags waarmee ze aangeven dat een document 'compatibel' is met hun eigen standaarden uit het verleden (zoals: ootnoteLayoutLikeWW8). Dat is voor een derde partij nooit te implementeren, omdat die standaarden niet vrijgegeven zijn.

Zie deze interessante weblog entry.

IBM heeft gelijk met alle verzet die ze plegen.
Er is ook geen noodzaak om iets te implementeren voor een derde partij.
Deze tags zijn bedoeld om aan te geven dat de files zijn gemaakt in een product met een afwijkende rendering op een bepaald gebied. Hiermee kan een nieuwe implementatie de gebruiker waarschuwen dan de rederring van een oud geconverteerd bestand kan afwijken van hoe de originele versie eruit heeft gezien. Er is geen enkele eis in OOXML dat de originele rendering wordt geimplementeerd. Dat is zelfs juist niet de bedoeling. Het is echter bijvoorbeeld bij conversies van oud drukwerk wel van belang dat een document nu er anders uit kan zien dan het origineel ondanks dat de data hezelfde is gebleven.
Nogmaals: Als MS office dat wel implementeert en andere softwarepakketten niet, zal het publiek klagen over de andere softwarepakketten, en zijn de makers dus door het publiek effectief wel verplicht deze te implementeren als Microsoft dit doet. Dit was te voorkomen geweest door die afwijkende rendering in de software en niet in de filestandaard op te nemen. Met name in het geval van datums is dit vervelend: MS Office houdt zich niet aan de ISO-datums. In plaats van MS-Office hier mee te laten stoeien, is dit nu onderdeel van de standaard.
Deze tags zijn bedoeld om aan te geven dat de files zijn gemaakt in een product met een afwijkende rendering op een bepaald gebied.
Een speciale tag die slechts bestaat om intellectueel eigendom te beschermen hoort niet thuis in een open standaard. Als Microsoft er een zogenaamd open HTML standaard met een <IE_only_foo_tag> door probeert te drukken, dan is dat ook niet prima. In een open standaard beschrijf je de afwijkende rendering met de tags die in de standaard zitten en dienen om, bijvoorbeeld, voetnoten en spacing te beschrijven.
Deze Office standaarden beschrijven helemaal geen rendering.
De betreffende tags zijn bovendien bedoeld voor backwards compatibility en niet voor gebruik in nieuwe documenten en dus niet voor het invoeren van MS only functionaliteit. Het is ook voor andere implementaties dan die van MS Office handig om te weten dat (alleen) bestaande geconverteerde documenten kunnen afwijken.

Als er gekozen was voor een oplossing waarbij MS ongedocumenteerde propriety compatibility items in de geconverteerde documenten had opgenomen (zoals OpenOffice dat doet) dan was er ook geklaagd over het verbergen van informatie.
En ondertussen het binaire .doc-formaat al jaaaaren angstvallig gesloten houden.

Iets met pot en ketel en zwart zien enzo.
Precies, een hypocriet die een hypocriet voor hypocriet uitmaakt is zelf hypocrieter dan hypocriet. :+
Inderdaad. Ik vind microsoft zo ongelovelijk hypocriet hiermee. Ze duwen zelf de meest uiteenlopende formaten bij de bebruikers door de strot en voelen zich beledigt zodra dat niet lukt. ooXML is misschien wel open, maar microsoft wil alsnog gewooon haar eigen formaat er doorheen duwen.

Ik geef ibm groot gelijk. Natuurlijk zal ibm ook wel ergens van te beschuldigen zijn, maar niet op het punt dat ze de concurrentie niet aankunnen. Microsoft is gewoon zo ongelovelijk lomp groot dat ze elk formaat door je strot kunnen duwen, open of niet. Dus dat is niet een eerlijke concurrentie.
Dat geven ze toch zelf ook toe

"Microsoft is zich duidelijk bewust van het feit dat het eigen verleden in dit opzicht ook niet helemaal brandschoon is. Maar: 'Wij hebben naar onze klanten geluisterd, en onze klanten willen een keuze hebben.' "

Dus beter lezen en dan pas bashen.

Persoonlijk vindt ik het een goede keuze dat de fabrikant van de software een Open formaat maakt. Ze kennen hun software het best. Het is ook aan de andere software schrijvers dan maar om de nodige aanpassingen te doen om het nieuwe "open" formaat te kunnen lezen.
"Microsoft is zich duidelijk bewust van het feit dat het eigen verleden in dit opzicht ook niet helemaal brandschoon is. Maar: 'Wij hebben naar onze klanten geluisterd, en onze klanten willen een keuze hebben.' "
Tja... nu er eindelijk actie is ondernomen, iedereen .doc zat is en er dan eindelijk een open standaard begint te leven, komt Microsoft aan met deze smoes. Nu moet er maar opeens op de mooie blauwe ogen van MS worden vertrouwd dat het beter wordt??? Wat denk je zelf...
@Royale de luxe:
Dat een computerleek in 't 'Open' van MS trapt, valt te begrijpen. Maar dat een 'tweaker' in zulke marketingtaal van MS trapt, is gewoon errrrug jammer...
Beter lezen slaat dan ook vooral op jezelf. Ten eerste verkracht MS 't woord 'Open', ten tweede: 'onze klanten willen een keuze hebben.': MS' manier van keuze bieden in dezen is niks anders dan een keuze uit gesloten MS-standaarden.
En iemand vertrouwen die na zoveel jaren van zeer bedenkelijke handelswijzen nog steeds vnl. bezig is met nog meer méér lock-in en dergelijke, is niet bepaald inzichtvol...
'Wij hebben naar onze klanten geluisterd, en onze klanten willen een keuze hebben.'

In het geval van Microsoft betekent keuzevrijheid dat je kunt kiezen tussen Microsoft, Microsoft of Microsoft.
En ondertussen het binaire .doc-formaat al jaaaaren angstvallig gesloten houden.
Je kunt ze natuurlijk ook gewoon opvragen via een licentieprogramma:
http://support.microsoft.com/kb/840817
Zoals ik het begrepen heb zijn beide standaarden niet goed / volledig.

De MS standaard is niet zo open als het zou moeten en de OO standaard is weer niet compleet dus voegen sommige pakketten weer functies toe waardoor er weer meerdere versies van zijn....
klopt wel ongeveer, beiden zijn niet ideaal.

ODF is dan wel niet volledig gespecificeerd, er zijn inmiddels wel meerdere open implementaties, die allemaal proberen compatible met elkaar te zijn. Dat is een groot verschil met OOXML, wat voorlopig maar 1 implementatie kent.

Hoe dan ook zit er wel vooruitgang in, en het is te hopen dat iedereen over 10 jaar gewoon het kantoorpakket kan gebruiken wat hij prettig vindt, niet wat anderen prettig vinden.
die allemaal proberen compatible met elkaar te zijn
Daar koop je dus niets voor. Een standaard is er juist om te zorgen dat je niet van dat soort compatibiliteits gedoe hebt.
@AHBdV
Daar koop je dus niets voor. Een standaard is er juist om te zorgen dat je niet van dat soort compatibiliteits gedoe hebt.
Je slaat de spijker op de kop.

Dit is zowel een sterk punt van OSS als een zwakte.
ODF wordt ontworpen door meerdere bedrijven, projecten en hobbyisten. Dit maakt het proces langzamer.
Microsoft kan feitelijk doen waar het zin in heeft.

ODF heeft als mooie dat het iets collectiefs en echt open is, maar het grote nadeel is dus dat de tot stand koming wat traag is. Microsoft precies andersom: Bepaalt alles in hun ééntje maar dat maakt het ontwerp proces veel sneller.

Ditzelfde zien we ook in OpenGL vs DirectX10.

Wat betreft de openheid van OOXML: Dat valt dus flink tegen. Voorbeeldje: "emulate word 97". Tja dat kan alleen MS zelf. Maar hiep hoi de specificatie is wel open.
Datgene wat er nog ontbreekt aan ODF, kan later worden toegevoegd aan versie 2 van de standaard. Welke functionaliteit ontbreekt er eigenlijk? Enige functionaliteit die ik ken zijn de problematische delen van OOXML.

Datgene wat niet open is aan OOXML, zorgt er voor dat het eigenlijk helemaal niet volledig geïmplementeerd kan worden door concurenten, en daardoor eigenlijk helemaal geen standaard is.
Het schijnt dat binnen ODF niet is vastgelegd hoe formules in een spreadsheet moeten worden verwerkt terwijl dit bij OOXML wel vast ligt. Als dat waar is lijkt dat mij een extreem goede reden om voor spreadsheet geen gebruik te maken van ODF. Stel je volgende formule voor: x = 1 + 2 * 3 In pakket A wordt deze fomule uitgerekend als (1 + 2) * 3 = 9 en in pakket B als 1 + (2 * 3) = 7.

Als een brief door verschillende suites op een verschillende manier word weergegeven is dat vervelend maar zelfs met een verneukte opmaak kan je meestal de informatie wel uit de tekst halen. Maar een spreadsheet waarbij je de resultaten van een berekening niet kan vertrouwen is waardeloos of zelfs gevaarlijk, je zou maar zo'n spreadsheet gebruiken om uit te rekenen hoeveel water je moet meenemen voor je trip door de Sahara of hoe sterk een constructie moet zijn.
* ODF bevat nog geen spreadsheet formule's
* Zowel ODF als OOXML bevatten (nog) geen gedefinieerde macro's ondersteuning.
* ODF bevat geen table ondersteuning voor spreadsheets
* Zowel ODF als OOXML bevatten geen ondersteuning voor office producten anders dan wordprocessing,spreadsheets en presentaties.
(database, calender, adressen enz)
keuze bij concumenten, ok

meer dan 1 standaard is ook niet goed.


Ik quote weer een Tanenbaum in zijn boek over netwerken:

Het probleem met standaarden is dat er zoveel zijn...

Dus laten we het dit keer proberen het op 1 standaard te houden. En ik zou het aan een onafhankelijke organisatie overlaten om deze te kiezen (in dit geval is dat ISO denk ik)
tannerbaum is wel slim maar zeker geen god.

Volgens jou logica zouden we nu allemaal met vi op een VMS systeem moeten werken. O nee, ook die producten hebben oudere "standaarden" verdrongen.....
Meerdere standaarden zuigt wel degelijk. Het levert extra conversiewerk, complexiteit en risico's op fouten op.

Iedereen die weleens met het imperialistische eenhedensysteem heeft gewerkt, en moest omrekenen tussen SI en imperialistisch, bijvoorbeeld Amerikaanse pound per square inch omrekenen naar Bar, zal het hier waarschijnlijk mee eens zijn.

De Am. petro-industrie en de Europeaanse hebben ook allebei hun eigen standaarden, wat ervoor zorgt dat vroeger een Am. pijp niet op een Eur. flens paste. Dit is slecht voor de klanten, hun materialen worden duurder omdat toeleveranciers twee formaten moeten ondersteunen, en onnodig als beiden het eens kunnen worden over één standaard. De markt laten uitmaken welke de uiteindelijke standaard wordt is dus onnodig langdurig, en te duur. Men kan veel beter samen om de tafel gaan zitten en tot één enkele standaard komen.

Helaas heeft Microsoft nooit een poging gedaan haar wensen voor officeformaten binnen de OASIS kenbaar te maken, ook al waren ze in het begin niet uitgenodigd. Het spreekt voor zich dat OASIS zeker naar de wensen van de industrieleider geluisterd had.
Microsoft had ook mee kunnen werken toen men begon met het standardiseren van ODF - maar iedere consessie die men moest doen naar het minder ondersteunen van het bestaande .doc formaat was taboe.

Als alternatief heeft men een serialisatie van het bestaande formaat naar XML gemaakt, inclusief alle bugs die in de bestaande .xls/.doc/.ppt formaten zitten.

Naast IBM zijn er ook andere (overheids) instanties die bezwaren hebben, vooral vanwege de inconsistentie van MS-OOXML en het feit dat je veel zaken (lees bugs) van MS-Office letterlijk over moet nemen.

Ik denk dat MS de tegenwerking vooral aan zichzelf te danken heeft!
Microsoft had ook mee kunnen werken toen men begon met het standardiseren van ODF - maar iedere consessie die men moest doen naar het minder ondersteunen van het bestaande .doc formaat was taboe.
Dat is gewoon FUD !!

Bij het begin van de ODF standaardisatie was MS ook helemaal niet gevraagd. Met is bij OASIS gewoon zonder meer op de eerste bijeenkomst meteen met het formaat van StarOffice/OOo begonnen. Het heette toen ook geen Open Document formaat maat Open Office formaat.
http://www.oasis-open.org...fice/200212/msg00003.html
Het gaat in die eerste bijeenkomst alleen maar over een formaat voor OpenOffice.org en helemaal niet over een ISO standaard over het betrekken van Microsoft bij de commissie (zou ook vreemd zijn om die te vragen bij de ontwikkeling van een open formaat bedoeld voor openoffice)

Later hebben ze de naam van de OASIS commissie veranderd om het product minder met OpenOffice te associeren en hebben ze het formaat OpenDocument genoemd.
OASIS is niet voor niets begonnen om een documentenstandaard op te stellen (al dan niet op basis van een eerder XML-based formaat) - juist om meerdere implementaties mogelijk te maken.

MS had dus aan kunnen voelen dat er andere apps dan OOo gebruik zouden gaan maken van ODF waardoor ODF de 'html van de office pakketen' zou kunnen gaan worden - meepraten had dus erg verstandig geweest, zeker toen er een roep kwam om een ISO-formaat voor office toepassingen.

Op zich zou OOXML een goed alternatief voor ODF kunnen zijn als men een consistent formaat neergezet zou hebben zonder alle MS-Office bugs in de specs.

Verder is het m.i. ook nog eens zo dat een XML-based office-formaat bedoeld moet zijn om compatibiliteit tussen office suites onderling en andere office gerelateerde toepassingen te bevorderen en niet om oude formaten als XML te presenteren..
en niet om oude formaten als XML te presenteren
Dat is juist een expliciete wens van bijvoorbeeld overheden en archieven. De gegevens in oude bestanden moeten leesbaar/beschikbaar blijven voor de toekomst onafhankelijk van de beschikbaarheid van een specifieke office implementatie.
De gegevens in oude bestanden moeten leesbaar/beschikbaar blijven voor de toekomst onafhankelijk van de beschikbaarheid van een specifieke office implementatie.
Precies!

Nu kan het zijn dat je meer informatie hebt dan ik - en dus ook precies weet wat de wensen zijn van de overheden en archieven. Maar dat geloof ik niet!

Ik kan me echter niet voorstellen dat de overheden en archieven hun gegevens zouden willen opslaan in een formaat dat by design bugs bevat (denk o.a. aan de presentatie van datums in OOXML). Ook zullen ze het mijns inziens niet op prijs stellen als er in het formaat mogelijkheden zijn opgenomen die niet publiek bekend zijn (alle referenties naar oude MS producten).

Natuurlijk is ODF ook niet het perfecte antwoord op alle vragen (spreadsheet uitwerking bijvoorbeeld), maar m.i. is het wel het formaat dat het minst naar het verleden kijkt en het meest naar de toekomst - en voor de geschetste problemen: ODF[een volgende versie] kan deze problemen natuurlijk gewoon tackelen...
Ik kan me echter niet voorstellen dat de overheden en archieven hun gegevens zouden willen opslaan in een formaat dat by design bugs bevat
Dat willen ze juist wel.
Er is namelijk geen betrouwbare conversiemethode om de oude spreadsheet bestanden de converteren naar een ander datum formaat zoals het ISO formaat.
Dat zou dus bijvoorbeeld bij documenten van notarissen of de belastingdienst heel erg belangrijk kunnen zijn !!

Wel zou ik het zelf netjes vinden als bijvoorbeeld Ecma tijdens deze ISO standaardisatie zich bereid verklaard om OOK iso datumformaten in OOXML spreadsheets te gaan ondersteunen in een volgende versie en daar een tijdlijn bij aangeeft. Dan biedt OOXML zowel backward compatibiliteit en/of performance zowel als voorwaartse compatibiliteit en interoperabiliteit voor spreadsheet datums.
Er is namelijk geen betrouwbare conversiemethode om de oude spreadsheet bestanden de converteren naar een ander datum formaat zoals het ISO formaat.
Dat zou dus bijvoorbeeld bij documenten van notarissen of de belastingdienst heel erg belangrijk kunnen zijn.
En over laten we zeggen 25 jaar weten we nog precies welke bugs er in OOXML geplaatst zijn!

Niet dus - door juist het formaat goed (dus zonder bugs) te specificeren en de serializer van office aan te passen -zodat deze de fouten van office corrigeert - kan MS de gemeenschap een dienst bewijzen. Zoals ze het nu geimplementeerd hebben is bijvoorbeeld 1900 een schrikkeljaar, maar bedenk wel dat volgens die logica ook 2100 een schrikkeljaar is!

Aangezien we naar de toekomst moeten denken (en ja 2100 is ver weg, maar dat dachten ze van het jaar "19100" (2000) ook) is het dus zaak om het formaat goed te specificeren.

]Ik geef toe dat ik nu ff focus op 1 aspect, maar de manier waarop MS dit aangepakt heeft dat stemt mij niet erg hoopvol over de kwaliteit van OOXML
Tja ,je blijft het welk leuk een bug noem maar het is gewoon een datumformaat.
Effectief is het een continu sequentieel numeriek formaat waarbij je alleen nummer 60 overslaat en begint te tellen bij 1900-01-01. Dat is eigenlijk natuurlijk doodsimpel te implementeren.
De beperkte iso xml datum representie in odf en andere delen van ooxml is een complexe stringrepresentatie datumtijd eventueel met tijdzone of een stringpresentatie van een periode beginnend op 1582-01-01 (meestal). Dat is natuurlijk helemaal niet zo simpel.

Het overslaan van de 60e dag in het datum1900 formaat is vreemd maar levert dus verder geen fouten op en het numerieke formaat is natuurlijk in spreadsheets een heel prettig formaat waar alle implementaties van odf het string formaat vermoedelijk direct converteren bij het inlezen en bij het wegschrijven. Een lastig probleem aanvullend probleem is bijvoorbeeld ook dat ODF niet voorschrijft hoe er in spreadsheets met periodes gewerkt moet worden hoewel dit wel een bestaand datum formaat is in ODF. Echter omdat ODF geen formula's bevat kun je ook niet zien of er formula's zijn die met datum periodes kunnen rekenen. Ik denk dat de meeste implementaties van ODF spreadsheets gekozen hebben om de datumperiodes in ODF gewoon niet te implementeren. En hoe ze omgaan met tijdzones is ook niet zonder meer elementair. Het is allemaal prima dat het in ODF zit maar er is eigenlijk weinig vastgelegd over hoe je met datums in ODF spreadsheets moet omgaan.

Het is dus zeker niet zo dat je zomaar even kunt zeggen dat ODF datums in spreadsheet beter heeft opgelost dan OOXML. Ze gebruiken gestandaardiseerde datums maar als je wilt weten hoe je er iets mee moet gaan doen moet je niet in de specs kijken maar moet je maar uitzoeken hoe OpenOffice dat doet of zoiets.

Er wordt zeer ongenuanceerd simpel over datums in spreadsheets gedacht maar het is complex.
De oplossing van OOXML biedt geen schoonheidprijs maar is niet moeilijk. De oplossing van ODF is mooi maar de uitwerking ervan verdient ook geen schoonheidsprijs.
Waar OOXML in een toekomstige versie misschien het iso datumformaat gaat toevoegen denk ik dat ODF wel eens kan kiezen op bijvoorbeeld ISO datumperiodes in spreadsheets uit te sluiten omdat het lastig is voor interoperabiliteit.
Ik zie OOXML/ODF (en welke andere opslag in XML dan ook) als serialisatie die te lezen moet zijn voor mensen - als wat het maar om het makkelijk te maken voor de programmeur die het formaat moet kunnen uitlezen.

Bij ODF is er (mijns inziens) voor gekozen om het XML formaat zo leesbaar mogelijk te maken, zodat de implementatie door anderen goed te doen is.

Zoals jij het zegt is de definitie van het datumformaat in OOXML een nummer die daarbij ook nog eens buggy gespecificeerd is, lekker als je dat als programmeur moet gaan implementeren.

* Little Penguin kan nog wel meer zaken in OOXML aanwijzen die minder mooi zijn geimplementeerd[/small] [small]Maar hetzelfde geldt ook voor ODF zoals je in je vele reacties hebt laten blijken. Punt blijft echter dat OOXML vooral bedoel is om als serialisatie van MS-Office interne datamodel te dienen en dat het voor concurrenten heel erg moeilijk wordt om deze goed te implementeren.

Overigens zijn er al wel 3rd party office apps. die (al dan niet rudimentaire) ODF ondersteuning hebben en daardoor ook beperkingen van ODF al naar voren hebben kunnen brengen - van OOXML is dat helaas (nog) niet het geval...
Dat is gewoon FUD !!
Sorry, maar dat is een verkeerd populistisch gebruik van de term FUD. FUD refereert aan Fear, Uncertainty and Doubt. Hier verwijs je er echter naar dat iemand geen gelijk heeft, wat niks met FUD te maken heeft. FUD is bijvoorbeeld als Microsoft zegt dat men inbreuk op haar IP maakt door bijvoorbeeld OpenOffice te gebruiken zonder bewijs.
Overigens had Microsoft voor zover ik weet in een veel later stadium welde kans mee te werken, maar kwam men nooit opdagen, zelfs toen het kon, wat al veel zegt over de interesse die men destijds had.
Dergelijk uitspraken zijn bedoeld om onzekerheid te stimuleren.
Zogenaamd wordt de indruk gewekt dat MS wel even had kunnen aanschuiven bij ODF onwikkeling in OASIS en dan geen eigen formaat nodig had.

Men is pas uitgenodigd toen er een uitgekristaliseerde spec op basis van OpenOffice lag en bijvoorbeeld het stadium van opties toevoegen voor compatibiliteit met miljarden legacy document voorbij was.

Bovendien wordt nooit door voorstanders genoemd dat OpenDocument helemaal niet een vooropgezet project was voor een ISO standaard maar slechts bedoeld was om juist OpenOffice meer interoperable te maken en dat alle deelnemers vauit die opzet betrokken waren bij het OpenOffice formaat en dat het in niemands hoofd opkwam om MS daarbij te betrekken.

Als je het geen FUD wil noemen dan is leugens misschien een goed alternatief ;-)
Zal ik dan maar even vertellen wat er mis is met ooxml en ms. Er zijn zat formaten te noemen die gesloten zijn en alleen met MS software werken. Een paar voorbeelden: .doc, cifs/smb, activesync, win32, wma/wmv. Concurrenten krijgen hierdoor geen kans omdat windows applicaties alleen op windows werken en .doc bestasnden alleen met ms office te openen zijn. Dat openoffice.org het .doc formaat heeft weten te reverse engineren, is een ander verhaal. Zo zou iets niet moeten gaan, in veel landen is het ook verboden. Door al die gesloten formaten hebben consumenten heel lang geen keuze vrijheid gehad. Een office suit gebruiken die geen .doc ondersteund kan niet. Je MOET ms office gebruiken.

Nu komt MS dan met een volgens hun open standaard. Dit is echt een enorm omslachtig standaard wat gebruik maakt van een hoop gesloten ms formaten. In het open formaat word er verwezen naar gesloten windows onderdelen. Daarnaast heeft ooxml allerlei tags voor het converteren van .doc naar .docx. Deze tags zijn niet beschreven in het standaard. Alleen MS weet hoe die tags werken.

MS is zelf lid van forum wat odf ontwikkeld. Ze hebben zelf invloed kunnen uitoefenen en het formaat kunnen verbeteren. Ipv. ODF te verbeteren, heeft ms besloten om nog maar een formaat te maken. Een formaat wat niet volledig open is en wat niet goed werkt op anderen besturingsystemen. Ooxml garandeert geen goede werking op non windows systemen, odf doet dit wel! Hoezo keuze-beperking?
"Nu komt MS dan met een volgens hun open standaard. Dit is echt een enorm omslachtig standaard wat gebruik maakt van een hoop gesloten ms formaten. In het open formaat word er verwezen naar gesloten windows onderdelen. Daarnaast heeft ooxml allerlei tags voor het converteren van .doc naar .docx. Deze tags zijn niet beschreven in het standaard. Alleen MS weet hoe die tags werken"

waar kom je met die wijsheid vandaan.
De "tags" zoals jij ze noemt dienen volgens mijn info enkel voor backwardscompatibility en hebben geen invloed op nieuwe documenten die je met dit formaat creeerd.
Trouwens Microsoft heeft geen invloed kunnen uitoefenen ze mochten slechts helemaal op het einde deel uitmaken en hadden niks in de pap te brokken , wel bij de feiten blijven hé.
"IBM heeft een wereldwijde campagne opgezet om overheden te overtuigen dat ze ooxml links moeten laten liggen."
Microsoft heeft ook een campagne gehad, met name in Massachusettes, om ODF links te laten liggen. Sterker nog, het liet de Boston Globe (krant) schrijven dat degene die bevoegd was en in Massachussettes ODF wilde, geknoeid had met reisdeclaraties terwijl dat achteraf onzin bleek te zijn (maar Peter Quinn is uiteindelijk wel opgestapt, en men lobbyde er hard voor de IT-organisatie die hierover ging en voor ODF was, haar bevoegdheden af te nemen.
Verder mobiliseerde Microsoft de visueel gehandicapten om, zogenaamd in het belang van gehandicapte mensen, maar in werkelijkheid in het belang van Microsoft, de overgang van Massachussets naar ODF tegen te houden.
Ed: De vraag wie nu werkelijk hypocriet is dringt zich dan ook zeer sterk op.
Zolang IBM binnen de regels van de wet blijft opereren en geen mensen omkoopt lijkt me er niets aan de hand. Logisch dat IBM en Microsoft tegengestelde belangen hebben hierin. Het is gewoon een concurrentieslag, eentje die al een lange geschiedenis heeft. Ik zie het punt niet zo.
ja, ja. vervang IBM door Microsoft denk aan de IE6 webstandaarden "discussies" hier op tweakers en zeg nog eens dat als IBM binnen de grensen van de wet blijft er niets aan de hand is.

IBM is, net als Microsoft, een bedrijf wat als voornaamste doel heeft om winst te maken. Daar is niets mis mee. Maar als Microsoft in deze gelijk heeft is IBM in mijn ogen duidelijk verkeert bezig. Zelfde geldt trouwens mbt het Groklaw gerucht.

Concurrentie is prima, maar IBM beleid (volgens Microsoft) met de mond het ene en doet in werkelijkheid wat anders. Dat is misschien niet verboden, maar maakt IBM niet geloofwaardiger en stelt haar claims mbt ODF en ooXML wel in een totaal ander daglicht.

Zal ik dan maar concluderen dat ODF alleen maar goed is voor IBM omdat IBM er geld aan denkt te kunnen verdienen? En dat hetzelfde geldt voor OpenOffice en alle andere fans van ODF. Laat ooXML maar lekker de concurrentiestrijd aan gaan. Keuzevrijheid en concurrentie is in mijn ogen namelijk vele malen belangrijker dan Microsoftje pesten.
Enige nuance, IBM steunt een formaat dat al een volledige open standaard is. Microsoft heeft in het verleden en nu nog bewust standaarden genegeerd en ervoor gezord dat mensen MS software moesten gebruiken om de veranderde standaard goed weer te geven.
Het groote verschil is dat ODF helemaal open en vrij te gebruiken is, en open XML heeft wat gemeene addertjes hier en daar onder het gras.

Of IBM geld gaat verdienen aan ODF? Misschien, maar hoe/waarom?

Ik denk, HOOP, dat IBM hier eigenlijk de 'good guy' aan het spelen is en oprecht een _fatsoenlijke_ volledige open standaard wil creeren/hebben.

(Misschien dit alles om hun eigen software beter te kunnen integreren/verkopen, prima toch, maar als je met IBM office, zonder problemen OpenOffice ODFs kan openen is iedereen toch blij?)
@oliveroms
Als voorbeeld van adder: in OOXML zit een instructie "emulate word 97". Laat een software maker dat maar eens implenteren.... Zo zitten er nog meer van die dingen in.

Microsoft probeert duidelijk de boel te saboteren. Dat hun specificatie meer dan 10 keer zoveel pagina's bevat als ODF, zegt ook wat...
@halfgaar: Microsoft heeft geen keuze. Ze kunnen natuurlijk met ODF gaan werken. Dan raken ze wel zo goed als alle functies van bv Excel kwijt (10 pagina's in ODF, 324 in OOXML) en kunnen ze backward-compatibility wel vergeten. Tenminste, tenzij ze ODF embracen en extenden. Dus wat heb je liever? Microsoft dat een concurrerende open standaard neerzet (ISO/ECMA is toch echt OPEN en Microsoft heeft meermalen aangegeven OOXML niet in bezit te willen/hoeven hebben), of Microsoft dat een bestaande standaard voorziet van zoveel extensies dat het alsnog bijna een eigen standaard wordt? Geef mij dan maar OOXML.

Overigens heeft de OOXML een regelafstand van anderhalf waar ODF er 1 gebruikt en bevat OOXML _alle_ gerelateerde specs waar ODF er alleen naar verwijst. Breidt ODF uit met de verwezen standaarden (javascript, DOM, SVG en wat niet) en geef het een regelafstand van 1.5 en opeens is het niet veel kleiner/groter dan OOXML.

Ohja, voor alle haterz die er ongetwijfeld om gaan zeuren: http://tirania.org/blog/archive/2007/Jan-30.html
Het groote verschil is dat ODF helemaal open en vrij te gebruiken is, en open XML heeft wat gemeene addertjes hier en daar onder het gras
OOXML is ook vrij te gebruiken.
Noem een even iets hoe je ODF wel mag gebruiken en OOXML niet ?
dat ODF alleen maar goed is voor IBM omdat IBM er geld aan denkt te kunnen verdienen
Het is ook goed voor Sun en Novell, die verdienen er ook geld aan, en voor de marktwerking en dus de klant, deze kan lock-in voorkomen, waardoor ISP's beter kunnen concurreren met elkaar en de klant een gunstiger tarief kan afdwingen. Het is een beetje willekeur IBM eruit te pikken en deze de zwarte piet toe te spelen voor dit alles.
Zal ik dan maar concluderen dat ODF alleen maar goed is voor IBM omdat IBM er geld aan denkt te kunnen verdienen? En dat hetzelfde geldt voor OpenOffice en alle andere fans van ODF. Laat ooXML maar lekker de concurrentiestrijd aan gaan. Keuzevrijheid en concurrentie is in mijn ogen namelijk vele malen belangrijker dan Microsoftje pesten.

Appels met peren vergelijken, en dan ook nog eens op een slechte manier vergelijken....

IBM verdient niet aan odf, en odf is niet door IBM gemaakt. Waarom ze zo tegen standaardisering van ooxml zijn (samen met een hele hoop andere mensen, en niet alleen uit de open-source wereld)? Ik ken de details niet maar ik heb al wel meerdere malen gelezen dat ooXML nogal al wat nadeeltjes heeft. Ten eerste omdat de standaard *veel* te omvangrijk is (er zit enorm veel in dat absoluut niet noodzakelijk is voor de toepassing, ie: documenten opslaan), ten tweede omdat de specificatie veel complexere en grotere xml files oplevert, en ten derde omdat er elementen inzitten die indirect naar gesloten standaarden verwijzen. Verwijzingen die invloed kunnen hebben op de opmaak van het bestand. Oftewel, degene die interoperabiliteit frustreert is niet (in ieder geval niet ALLEEN) IBM.

Komt nog eens bij dat ik het argument 'keuzevrijheid' dat MS aanvoert in de context van een bestandsformaat niet helemaal terecht vind. Keuzevrijheid is vaak een goede zaak, maar in het geval van office documenten zou ik de voorkeur geven aan EEN formaat dat door ALLE tekstverwerkers VOLLEDIG gelezen/weergegeven/geschreven kan worden. Dat zou dan .odf moeten worden. Wat heeft een gebruiker er in hemelsnaam aan als ie tussen 20 verschillende 'standaard' formaten te kunnen kiezen :?
Kortom, Microsoft beschuldigt IBM nu van alle zaken waaraan ze zich zelf schuldig hebben gemaakt. Maar goed, hypocriet zijn betekent nog niet dat ze ongelijk hebben.

Alleen hebben ze dat wél, want Microsoft doet het voorkomen alsof IBM ze gewoon met rust zou moeten laten en Microsoft moet laten standaardiseren wat ze leuk vinden. Alsof kunnen schermen met een ISO standaard die op je eigen producten gebaseerd is geen belangrijk strategisch voordeel oplevert...

ooxml is niet zo open als Microsoft beweert (zie Wikipedia), en het is IBM's goed recht om daar bezwaar tegen te maken. "Ja, vroeger waren onze bestandsformaten allemaal gesloten, maar nú zijn onze gesloten bestandsformaten gestandaardiseerd! Lang leve de open standaarden die iedereen kan implementeren, in theorie! U kunt met een gerust hart Microsoft blijven gebruiken voor uw documenten."

Je moet toch serieus je broek ophijsen wanneer Microsoft ijskoud zegt dat "het bedrijf probeert het standaardiseringsproces te misbruiken om keuzevrijheid in te perken, en uiteindelijk doen ze dat alleen maar om er geld aan te kunnen verdienen". Pardon, ging het hier nou over IBM of over Microsoft? Dit is een sterk staaltje van geen spier vertrekken.
Verder vraag ik me af waarom we in 's hemelsnaam x fileformaten zouden moeten standaardiseren. In het verleden heeft MS nog nooit een echte poging gedaan om haar formaten implementeerrbaar te maken voor anderen en moest men er met reverse engineering maar achter zien te komen.

Nu klanten open standaarden steeds belangrijker gaan vinden probeert MS een standaard te maken van een eigen formaat. Op zich niets mis mee, ware het niet dat er al een ISO standaard is en dat ooxml een aantal nare kantjes heeft zoals een onvolledige sepcificatie ("bullets als in Word 6"), zondigt tegen andere bestaande ISO standaarden (datumformaat bijvoorbeeld) en nog altijd de schijn tegen heeft als het gaat om gepatenteerde delen.

Kortom, bepaalde bezwaren tegen ooxml zijn zeer terecht en de ISO moet zich terdege realiseren wat hier gedaan wordt. MS komt op mij nu over als een klein kind dat haar zin niet krijgt en nu maar heel erg hard gaat roepen dat de ander het gedaan heeft.

Volgens mij verkoopt MS geen standaarden maar software. Als ze er nu voor zorgen dat hun software goed met standaarden overweg kan en meer waar voor het geld levert dan de spullen van de concurrentie is er geen vuiltje aan de lucht voor onze vrienden uit Redmond. Dat ze het anders gewend zijn wil niet zeggen dat dat altijd zo moet blijven.

Het lijkt mij als gebruiker heerlijk om zelf te kunnen kiezen welk Officepakket ik kan gebruiken zonder dat ik tegen problemen aanloop met het lezen en bewerken van files die in een ander pakket gemaakt zijn.
Volgens mij verkoopt MS geen standaarden maar software.
Kennelijk heeft MS niet zoveel vertrouwen in haar software, en heeft men idee dat de meerwaarde van MS Office niet zit in de software zelf, maar in de standaarden die het gebruikt. Als MS goed met standaarden en ODF overweg kan, en MS macro's / VB naar een open standaard overgezet kunnen worden, is de meerwaarde van MS Office, afgezien van Access en vastgeroeste gebruikers, totaal verdampt.
Hoewel ik een groot voorstander ben van een standaardisatie ben ik al blij dat in de nieuwe versie(s) van Office en OO meerdere typen bestandsformaten worden ondersteund.

Alleen nu IBM een standaard heeft gemaakt gaat MS met de hakken in het zand.

Is het niet eenvoudiger om ook deze standaard met behulp van een plug in beschikbaar te maken ipv IBM hypocriet te noemen?
Is het niet eenvoudiger om ook deze standaard met behulp van een plug in beschikbaar te maken ipv IBM hypocriet te noemen?
Niet genoeg. MS claimt dat er een markt is voor twee standaarden, met ODF als open document formaat (open en volledig gespecificeerd, maar kan bepaalde Word-specifieke zaken minder goed dan ODF) en OOXML als archiveringsformaat (completer, meer Word-compatible, veel backwards-compatible tricks die anderen niet kunnen implementeren). Als dat echt zo was, dan zou Office ODF als standaard gebruiken en OOXML eventueel via een plug-in distribueren voor die bedrijven die het voor archivering nodig hebben.

Het feit dat het omgekeerd is geeft al aan waar het MS om gaat: ze willen gewoon de markt angstvallig in haar moordende wurggreep houden.
Is het niet eenvoudiger om ook deze standaard met behulp van een plug in beschikbaar te maken ipv IBM hypocriet te noemen?
Dat doen ze bij Microsoft momenteel allebei.
Alleen nu IBM een standaard heeft gemaakt gaat MS met de hakken in het zand
Nee, het moet zijn:
Alleen nu MS ook een open standaard heeft gemaakt gaat IBM met de hakken in het zand
Is het niet eenvoudiger om ook deze standaard met behulp van een plug in beschikbaar te maken ipv IBM hypocriet te noemen?
Die is er al
'Het bedrijf probeert het standaardiseringsproces te misbruiken om keuzevrijheid in te perken, en uiteindelijk doen ze dat alleen maar om er geld aan te kunnen verdienen'

Pot <--> ketel

Wat is nu eigenlijk het probleem? Dat Microsoft een standaard probeert door te drukken voor iets waar al een standaard voor is?
Waarom de moeite doen om een ooxml door te stampen als er al odf is wat voorziet in precies hetzelfde nut.
Enige reden volgens mij is dat Microsoft bang is geld te verliezen en dus hun best doen hun eigen standaard door te forceren... As usual :)

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