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 , , 67 reacties
Bron: ECMA International, submitter: 80466

Microsoft-werknemer Brian Jones heeft bekendgemaakt dat het Office XML-bestandsformaat in de laatste fase voor officiŽle standaardisatie zit. Twaalf organisaties - waaronder Apple, Barclays Capital, Intel, Novell en Microsoft zelf - hebben hun goedkeuring verleend aan de definitieve versie van de omschrijving van de Office XML-standaard, wat betekent dat het document in zijn huidige vorm naar de Ecma gestuurd kan worden. Op de vergadering van 7 en 8 december zal over het voorstel gestemd worden bij de Ecma, waar het voorstel hoogstwaarschijnlijk geaccepteerd zal worden. Het standaardiseren van het Office-formaat, moet het Microsoft gemakkelijker maken zijn waren te slijten aan overheidsinstellingen die open formaten eisen.

Moderatie-faq Wijzig weergave

Reacties (67)

Heel verstandig van Microsoft! de enige manier om je spullen te blijven verkopen is zorgen dat je de beste bent, niet mensen dwingen jouw product, en alleen dat van jou te kopen.
nou de beste is nog maar de vraag (dit moet je namelijk altijd in verhouding zien tot 't doel) en euh dit is nouw niet bepaald iets waar MS gelukkiger van word, maar ze "MOETEN" gewoon om geen grote klanten kwijt te raken aan andere office pakketten.
Interessante ontwikkeling. Mogelijk wordt dit formaat zowel door MS-Office als de Novell versie van Open Office ondersteund.

Goede ontwikkeling voor de consument.
Op zich zal OpenOffice dit formaat wel gaan ondersteunen, maar ergens lijkt het mij wat overdreven om 2 XML-standaarden te hebben voor documenten. Maar goed, welbeschouwd zijn bv SGML en DocBook ook al open standaarden voor doumenten, alleen zijn die te zwaar om in een tekstverwerker te stoppen (en voor de gemiddelde en zelfs gevorderde gebruiker te ingewikkeld).
En deze standaard komt er alleen omdat MS anders niet meer bij diverse overheden binnenkomt... En MSOffice in combinatie met de concurerende ODF niet voldoende performance zou halen.
gaat microsoft zich eindelijk aan standaarden houden? lol :+
nou als ze dat al doen dan toch in iedergeval zo dat andere 'spelers' toch 'net' niet helemaal mee kunne in de race,
mijn gevoel zegt me dan ook dat ik liever zie dat er meer aandacht zal worden besteed aan de optimalisatie van het ODF dat is tenminste ECHT open
ODF is niet meer open dan OOXML
Geef anders maar eens iets concreets aan waarin ODF meer open is !!
De licentie van OpenXML is net zo open als die van ODF.
Los van het feit dat de specificaties gepubliceerd zijn is de licentie van OpenXML:
- royalty-free
- non-perpetual (eeuwigdurend)
- non-discriminatory (iedereen mag en kan het implementeren)
- je mag ook delen van de standaard implemteren
- hergebruik is toegestaan
- etc. etc.

En er is een Covenant-Not-to-Sue (CNS) waarbij beloofd wordt dat er geen aanspraak gemaakt wordt op eventuele patenten. Dit is vergelijkbaar met de CNS die Sun opgesteld heeft voor Sun patenten in ODF. Het is zelfs toegejuicht door Larry Rosen (voormalig OSI general counsel): http://blogs.zdnet.com/BTL/?p=2192

Dus ik snap niet helemaal waarom onze licentie verschilt van de ODF licentie? Of waarom de deur bij OpenXML op een "kiertje" zou staan? De deur staat net zo open als met ODF en we kunnen "de deur niet eens sluiten" want de licentie is non-revocable...

Raul Pesch
Microsoft
Klopt, ik haal de licentie en standaard door elkaar, excuses. De OpenXML licentie is onder druk van derden idd net zolang aangepast totdat deze praktisch hetzelfde was als de ODF licentie, aangezien de ODF licentie voldeed aan de eisen gesteld door overheden.

De rest van de discussie hebben we eerder gehad. Microsoft had kunnen deelnemen in OASIS, maar ik heb van aanwezigen gehoord dat ze nooit aanwezig zijn geweest bij besprekingen ed. Ze hadden dan ODF compatibel kunnen maken en meer functies kunnen geven. Dit hebben ze echter niet gedaan, waarschijnlijk omdat ze dachten dat een eigen -extra- standaard een meerwaarde voor hun had, en dat die meerwaarde via de ECMA sneller (dus goedkoper) verkregen kon worden. Mede daarom vragen mensen als ik zich af waarom het ECMA en niet OASIS gekozen is. Het kan haast niet anders dan dat MS makkelijker z'n zin kreeg bij de ECMA; wat ook blijkt aan de vraagstelling aan ECMA, die er bijna op neer komt: Ontwikkel een standaard die compatibel is met ons bestaande bestandsformaat en die klaar is om bij de ISO in te dienen als 'concurrent' voor de al bestaande ISO norm.

Als iemand die dagelijks met ISO normen werkt wil ik graag opmerken dat het buitengewoon vervelend is als twee normen elkaar bijna overlappen en proberen te beconcurreren. Gelukkig is er in mijn branche wel gezonde concurrentie, wat ervoor zorgt dat er niet een bedrijf op eigen houtje een bestaande goedgekeurde ISO norm ten behoeve van haar welzijn, gemak en winst probeert te 'vernieuwen/veranderen'.

Snelheidsterugval is door MS handig ingedekt: Als ik een snelheidstest wil doen moet ik volgens bepaalde MS EULA's toestemming vragen aan MS om mijn eigen(!) benchmarks te publiceren, en bovendien wordt ik verplicht voor de MS-software alles te optimaliseren. Logisch dat dan uit alle benchmarks zal blijken dat OpenXML sneller is. Respect voor zulke sneaky acties!
De licentie... En da's heel bepalend. ODF is vrij en open. OpenXML is 'op een kiertje', zodra je de vingers in het spleetje steekt trekt Microsoft gauw de deur dicht.
@rpesch
Although it’s not clear whether or not Microsoft would clamp down on partial implementations of its file formats, the fact that Microsoft is promising not to sue those who fully comply without having a test for that compliance creates a fair amount of uncertainty
Die CNS gaat alleen over volledige implementaties van de standaard. Helaas staat er nergens gedefinieerd wat er onder volledig verstaan word en is er ook geen formele set tests voor. m.a.w. Dat CNS is zo goed als waardeloos.

Zelfs al zou dat CNS zinnig zijn, is het nog steeds een enorme drempel om ook maar iets te maken wat met OOXML kan omgaan. Je kan immers alleen veilig een *volledige* implementatie van de standaard maken. Een tooltje om plaatjes te converteren in een .docx is dus al onmogelijk, want dat implementeert maar een klein gedeelte van de standaard.

Verder moet je toegeven dat Microsoft nu niet bepaald een bewonderigenswaardige reputatie heeft op het gebied van conformeren aan standaarden (zelfs aan de eigen), openheid en aanverwantte zaken. Ik zou er mijn bedrijf niet op riskeren tot een jurist of bij voorkeur een rechter dat CNS beoordeeld heeft.
@rpesch:

Die quote over niet gegarandeerde vrijwaring van gedeeltelijke implementaties onder de CNS komt uit je eigen link. Je draagt dus zelf documentatie aan die je eigen ongelijk bewijst, chapeau!
@R.Pesch:
Dus ik snap niet helemaal waarom onze licentie verschilt van de ODF licentie?
Als de twee zo gelijk zijn, dan moet je toch eens aan je werkgever vragen waarom ze geld over de balk gooien door zelf een nieuwe licentie te moeten ontwikkelen terwijl er al een bestond. Jaja, de OpenXML standaard is uitgebreider, om het voor bedrijven met minder werknemers lastiger te maken om ermee te werken.

Larry Rosen zegt trouwens ook:
Rosen: Software always changes. In later versions. Microsoft may indeed try to lock its customers into a proprietary fork. But THIS version is open and we should acknowledge it.
De CNS van Microsoft vrijwaart ook patenten op gedeeltelijke implementaties. Zelfs als die gedeeltelijke implementatie hergebruikt wordt in een ander product. Tooltjes om plaatjes te converteren vallen onder de CNS. Het is een zogenaamde "blanket coverage" die zoals eerder gezegd weinig verschilt van Sun's CNS.

En die juridische blik op de CNS is er reeds geweest door Larry Rosen, tot voor kort een van de bekendste "open source juristen": http://blogs.zdnet.com/BTL/?p=2192
Helaas staat er nergens gedefinieerd wat er onder volledig verstaan word en is er ook geen formele set tests voor.
In de standaard staat precies gedefinieerd waneer een bestand aan de standaard conformeert. Daar is dus heel duidelijk gemaakt wanneer je wel of niet voldoet aan de standaard.
Zie ook paragraaf 2.4 2.5 en 2.6 van de final specs:
http://www.ecma-internati...01%20-%20Fundamentals.pdf

Een quote uit deze spec
For the guidelines to be meaningful, a software application should be accompanied by publicly available documentation that describes what subset of this Standard it supports.
Jou bewering slaat dus nergens op.
De ODF standaard is zo te zien juist de standaard waarbij niet duidelijk is wanneer je wel of niet voldoet aan de standaard. Het is volstrekt onduidelijk wanneer je een bestand wel of niet OpenDocument mag noemen omdat de eigenaar van deze merknaam, de OASIS foundation, dat niet heeft gespecificeerd !!!
@Gerco: Ik verwijs met de link naar de statements die Larry Rosen heeft gemaakt over de CNS, en niet naar een intepretatie die de blogger "David Berlind" er op nahoudt.

Dit is letterlijk wat Larry Rosen zegt:
This covenant is at least as generous as the patent licenses for many other document formats and industry standards. It includes protection for Microsoft against patent lawsuits; this is just like the patent defense provisions in many open source licenses.

And the scope of their patent covenant, even though it is limited to "conforming" software products, is sufficient to allow open source implementations that can read and write Office 2003 documents.

Microsoft’s covenant is, to coin a phrase, as fair and balanced as other licenses or covenants we’ve accepted before. I am pleased to see Microsoft move their patent licensing strategy this far.
Jouw interpretatie van de tekst dat alleen "volledige" implementaties van OpenXML zouden zijn gevrijwaard van patentclaims is incorrect. Dit komt door een incorrecte interpretatie van het woord "conforming". "Conforming" in deze context betekent simpel gezegd dat we alleen patenten vrijwaren die conform de OpenXML specificatie (of een deel daarvan) zijn. We willen vanzelfsprekend voorkomen dat iemand andere patenten van Microsoft (die niets met OpenXML te maken hebben) of patenten van derden in de implementatie verwerkt en vervolgens de CNS gebruikt om zichzelf te vrijwaren van claims.

Er is een interessante (als je een jurist bent) analyse van Baker en McKenzie die hier tot op detail op ingaat:

[quote]
The second qualification concerns the scope of Microsoft patents: it is designed to put users on notice that a conforming implementation of the Schema may not include a patent claimed by Microsoft or, if the
conforming implementation does include such a patent, that the patent may not be enforceable.

The third qualification addresses the intellectual property
rights of others that any conforming implementation of the Schema may contain. Microsoft is not in a position to protect users from any such third party infringement.[b]The second and third qualifications are designed to protect Microsoft from any liability arising from the implementation of the Schema./b]
[/quote]

http://www.bakernet.com/N...0867/0/OpenXML.pdf#search=%22%22conforming %22%20software%20products%20openxml%20cns%22

De Microsoft CNS voor OpenXML verschilt hierin niet van de CNS die Sun voor ODF heeft opgesteld!

[quote]
Microsoft’s CNS is similar to a covenant issued by Sun Microsystems Inc.,
in September 2005, in respect of any patents that it holds in respect of the
Open Document Format (‘ODF’) for Office Applications (OpenDocument)
v1.0 Specification (‘Sun’s Covenant’)15.
[/quote]

<vergelijking Sun CNS voor ODF en MS CNS voor OpenXML toegevoegd>
Bedenk wel dat de standaard een Ecma standaard is. Microsoft kan daar geen licentievoorwaarden op leggen.
In theorie kan Microsoft wel een toekomstige eigen variant creeeren die niet meer voldoet aan de in de OOXML standaard geregelde extensibility.
Maar dan is hun applicatie dus niet meer compatible met een open standaard. Dat zou een domme actie zijn als allerlei overheden dat als een eis stellen. Die zullen dan niet overgaan op het nieuwe fomaar maar de oude programmatuur met het open fromaat blijven gebruiken. Geen goede zakelijke keuze. Zeker aangezien MS nieuwe versies ook prima bij Ecma kan onderbrengen.

Sowieso heeft de Ecma standaardisatie het formaat aanzienlijk verbeterd. De eerste OOXML draft was zowat onleesbaar en erg onvolledig maar de huidige is aanzienlijk beter. Overigens zie ik nog steeds veel ruimte in de beide specs van ODF en OOXML voor verbetering. Zo is ODF is nog niet echt af en OOXML bevat nog te veel legacy ballast.
@R.Pesch:
Dus ik snap niet helemaal waarom onze licentie verschilt van de ODF licentie?

Als de twee zo gelijk zijn, dan moet je toch eens aan je werkgever vragen waarom ze geld over de balk gooien door zelf een nieuwe licentie te moeten ontwikkelen terwijl er al een bestond. Jaja, de OpenXML standaard is uitgebreider, om het voor bedrijven met minder werknemers lastiger te maken om ermee te werken.
Je haalt de termen licentie en standaard door de war. Onze licentie (de gebruiksvoorwaarden) verschillen weinig van de ODF licentie. Beide zijn royalty-free, beide zijn perpetual, beide zijn non-discriminatory etc.

Dat is totaal wat anders dan de standaarden OpenXML en ODF.
Simpel gezegd moet je als Microsoft rekening houden met de wensen en eisen van honderden miljoenen Microsoft Office gebruikers wereldwijd. Bestaande gebruikers verwachten niet anders dan dat je minimaal dezelfde functionaliteit biedt als voorgaande versies, dat je compatibel bent met de miljarden documenten in het oude formaat die reeds in omloop zijn en dat het snelheidsverschil minimaal is. OpenXML is gebasseerd op de functieset van Microsoft Office. ODF is gebasseerd op de functieset van Open Office. Een keuze voor ODF als standaard bestandsformaat in Office 2007 zou voor miljoenen gebruikers een stap terug zijn geweest in functionaliteit, compatibiliteit en snelheid.
Als iemand die dagelijks met ISO normen werkt wil ik graag opmerken dat het buitengewoon vervelend is als twee normen elkaar bijna overlappen en proberen te beconcurreren. Gelukkig is er in mijn branche wel gezonde concurrentie, wat ervoor zorgt dat er niet een bedrijf op eigen houtje een bestaande goedgekeurde ISO norm ten behoeve van haar welzijn, gemak en winst probeert te 'vernieuwen/veranderen'.
Misschien handig om daar het licht over te laten schijnen van iemand die voor het betreffende ISO TC34 committe werkt:
http://www.oreillynet.com...ts_of_ecma_office_op.html
http://www.oreillynet.com...t_by_odfs_definition.html
Maar jou gelul over dat de CNS niet geldt voor gedeeltelijke implementaties slaat ook nergens op omdat de standaard namelijk inclusief een gedeeltelijke implementatie conformeringclausule komt.

Als er iemand ongelijk hebt ben jij het wel. Maar je hebt dan ook duidelijk geen idee wat er in de standaard staat terwijl je er wel commentaar op levert. Dus is een zinvolle reactie waarschijnlijk ook moeilijk te verwachten.

Misschien ook nog een handige link voor jou met betrekking tot patenten en Ecma standaards:
http://www.ecma-international.org/memento/codeofconduct.htm
De bovenstaande code of conduct geldt voor ALLE Ecma standaards en bijvoorbeeld niet voor ISO standaards.
Correctie: Microsoft laat zijn eigen producten als standaard erkennen :)
Ik wou al zeggen:

Microsoft houdt zich best vaak aan standaarden. Jammer genoeg zijn dit vaak slechts hun eigen standaarden en niet de standaarden die de rest van de wereld erkent.

Hoewel daar in dit geval een beetje verandering in zit te komen doordat ze hun eigen standaard nu laten erkennen door (een klein deel van) de wereld...

Maar zoals hieronder al gezegd, ik zou toch liever het ODF formaat gebruiken.
@hAL

WP zegt: over OpenXML:
Also included in the ZIP package will be embedded (binary) files like PNG, JPEG OR GIF images.
De enige die reacties gebaseerd geeft op lucht ben je zelf, geef anders maar eens aan waar in de omschrijving staat dat er GEEN closed source binaries in mogen zitten. Je geeft zelf namelijk ook geen bron.
Om je op weg te helpen, de drafts staan hier.

BTW regel 24 / pagina 75 / Part 1 wordt gesproken over binary info.
Zie hoofdstuk 12.3.5, "Custom Property Part". Jammer dat je zelf geen tegenonderzoek doet, zo moeilijk kan het toch niet zijn als ik het ook kan vinden.

-edit-
Probleempje voor jou is dat ik grote delen van de Engelse wikipedia artikelen van zowel OOXML en Opendocument zelf geschreven heb.
Haha, geschreven? In de history zie ik dat men je een 'notoire spammer' vindt. Zie oa hier waar je willens en wetens verschillende MS licenties door elkaar fietst (laatste paragraaf). Zou me haast verkeerde dingen gaan afvragen...
Het ziet er naar uit dat we in Ha1 weer een Microsoft werknemer inhuis hebben. De vraag is, gaat Ha1 net zo sportief doen als Raul Pesch en het gewoon toegeven of niet? Je spam op wikipedia spreekt in ieder geval boekdelen.
@MooiLaarzen: Dat OpenXML uitgebreider is dan ODF, is precies de valkuil waarin MS jou, en met jou allerlei niet al te nozele ontwikkelaars laat lopen.
Belangrijk is dat het /slechter/ is dan ODF. Er is een aantal punten maar het bebangrijkste is waarschijnlijk dat de MS implementatie van OpenXML standaard bol staat van de binary blobs, die alleen door MS tools geinterpreteerd kunnen worden. De XML standaard staat dit toe, in die zin is het dus open te noemen, maar voor partijen buiten MS is het weer een niet-werkbare reverse-engineer en altijd-achterlopen situatie.
Er is een aantal punten maar het bebangrijkste is waarschijnlijk dat de MS implementatie van OpenXML standaard bol staat van de binary blobs,
Jammer dat je daar geen geen bron van deze infomatie bijzet . Lijkt me ook lastig want het klinkt gebaseerd op lucht...
Als grote spelers als Apple, Intel en Novell het steunen, dan is dat zeker wel interessanter dan ODF
het is nu nog wachten op andere office suites die het gaan ondersteunen. ODF wordt gesteund door een aantal grote jongens (SUN, Novell, IBM, Google, Corel) en heeft nu redelijk wat office suites die het ondersteunen (IBM workplace, openoffice.org, google writely, etc.). Er zitten nog wat fouten in sommige implementaties, maar dat wordt nog wel opgelost. Een Openxml office suite kun je vooralsnog alleen bij Microsoft kopen, dus als klant ga je er niet echt op vooruit. Je keus als je niet tevreden bent met het product neemt niet toe door het gebruik van openxml.

Dus voorlopig heeft ODF een hele grote voorsprong op openxml.
Je vergeet nog de heel interressante KOffice office suite die ODF ondersteunt.
Corel zal overigens vermoedelijk OpenXML gaan ondersteunen aangezien ze dat al hadden aangekondigd maar wat ze native gaan gebruiken in hun Office suite is nog onzeker. Nog een Office format misschien ???
Verder zij er al heel wat commerciele applicatietjes bezig met OpenXML.
Nu is natuurlijk de tijd waarin je een OOXML product kan ontwikkelen dat commercieel interessant is icm met MS Office 2007. Ik wou dat ik een goed idee had voor een dergelijk product.
Corel gaat OpenXML ondersteunen in WordPerfect Office X3:
http://www.eweek.com/article2/0,1895,1917723,00.asp
WordPerfect Office X3 will support Office 12's OpenXML format. The Corel suite will not support OASIS' Open Document Format for Office Applications standard, although Corel remains an active participant on the OASIS technical committee for ODF.
Sun gaat OpenXML ondersteunen in StarOffice:
http://www.sun.com/softwa...e/faqs/technical.jsp#q_18 (antwoord op vraag 18)

Novell heeft reeds een prototype laten zien van een OpenXML implementatie voor Open Office.
@jeroen2
Je bent een sukkel door zonder meer dingen aan te nemen over andere mensen.
Jij bent wel heel erg desperate. Ik neem geen dingen zonder meer aan: heb even de tijd genomen om jou activiteiten op wikipedia onder de loep te nemen en kwam tot dezelfde conclusie als kidde.

Grappig dat jij je door mijn opmerking zo aangevallen voelt dat je meteen moet gaan schelden. Behoorlijk stijlloos...
OpenXML is uitgebreider dan ODF. Als grote spelers als Apple, Intel en Novell het steunen, dan is dat zeker wel interessanter dan ODF.
Ben erg benieuwd wat OpenXML allemaal voor een extra nuttige mogelijkheden heeft!
[offtopic]zeker weten? al eens geprobeerd een word 95 bestand te openen in word 2003 of andersom?
loby-en doet een boel hoor.

Daarnaast kun je als apple moeilijk niet comply-en.
Of moet apple alleen oasis nog ondersteunen, z'n campatibility met office maar opzeggen?

Daarnaast is een XML formaat een XML formaat, maar die van MS had geloof ik nu al overal binary blobs zitten (die dus niet goed gedocumenteerd zijn, en alsnog propeitary stuff kunnen bevatten)
Het probleem met ODF is dat de standaard niet compleet is. Elk officepakket die ODF implementeert geeft er een eigen draai aan. Je kunt een OpenOffice Calc document niet openen in KSpread, omdat beide een eigen invulling hebben gegeven aan de manier om formules te gebruiken. Dit is nml niet opgenomen in de ODF standaard, omdat ze snel die OASIS standaard "af" wilden hebben voor certificering.
WP zegt: over OpenXML:Also included in the ZIP package will be embedded (binary) files like PNG, JPEG OR GIF images..<knip>...Om je op weg te helpen, de drafts staan hier
Probleempje voor jou is dat ik grote delen van de Engelse wikipedia artikelen van zowel OOXML en Opendocument zelf geschreven heb.
En de locatie van de draft ken ik ook want ik heb grote delen van de OOXML 1.4 drafts en van de final ODF specs ook gewoon gelezen.
geef anders maar eens aan waar in de omschrijving staat dat er GEEN closed source binaries in mogen zitten
Natuurlijk kunnen er zowel in de ODF als in de OOXML specs gewoon embedded closed source binary files zitten. Dat is ook logisch want anders kun je geen media files zoals plaatjes/geluid/video kwijt in office documenten.
Als jij dus morgen je eigen closed source 'kidde' formaat voor plaatjes creert dan kun je dat direct in een OpenDocument kwijt en voldoe je toch direct aan de ISO standaard. Evenzo met OOXML.
Dergelijke binary media files zullen als los bestand in het ZIP pakketje worden opgenomen.
Het feit dat je de formaat specificatie spec aangeeft dat je files kunt embedden in een office document betekent dus nog niet dat de XML formaat specificatie zelf de mogelijkheid tot het creeren van interne binaries met office document info bevat.

Het is denkelijk mogelijk dat je een oude binary .doc files embed in een ODF file. De ODF spec beschrijft een dergelijke sitatie niet maar laat deze mogelijkheid wel toe.

Office applicaties kunnen dus ook 100% voldoen aan de beide specs zonder dat ze de mogelijkheid bieden om de embedden binaries te openen / tonen . Echter de meeste grote office applicaties zullen naast de XML specs ook een flink aantal van de bekendste embedded binary formaten zoals jpg direct ondersteunen en deze niet via externe applicaties openen.
@jeroen2
Je bent een sukkel door zonder meer dingen aan te nemen over andere mensen. En dat kan ik rustig hier zeggen omdat ik me niet aan een baas hoef te verantwoorden !! }>

En gek genoeg bestaat het redigeren van artikelen op wikipedia voornamelijk bestaande uit het verwijderen van spamlinks en door de tijd achterhaalde informatie.
Nee ze maken nieuwe standaarden :P
Nu nog wachten op de ISO standardisatie van het 'Office Open XML' formaat.

Eerder zullen overheden en de EU hier niet op overstappen...
Niet overstappen als in 'Ze gebruiken het niet-gecertificeerde Word formaat ook niet?'
Vermoedelijk zal het ISO standaardisatieproces direct aanvangen na de Ecma standaardisatie.
Als ze dat via een fasttracking proces doen zoals bij ODF dan duurt dat nog een maand of 9-12.
Overigens voldoet een Ecma standaard vrijwel altijd aan Europese regelgeving tenzij er expliciet ISO staat. Ecma standaarden zijn over het algemeen meer open en gratis dan ISO standaarden .
maakt niet uit, microsoft stopt zijn eigen XML toch vol met eigen binary formaten die gepatenteerd zijn.....
De OOXML standaard bevat geen verborgen binary elementen. Je kunt wel binary elementen zoals plaatjes embedden maar dat kan evenzo in ODF.

Bovendien OOXML is straks een open Ecma standaard.
Net als bijvoorbeeld Javascript.
Microsoft kan wel bijdragen in de ontwikkeling van de standaard maar is geen eigenaar meer van die standaard !!
Office Open XML of ODF, welke is technisch gezien beter? Wat kan de 1 wat de ander niet kan?
Kort gezegd, OpenXML ondersteunt alle features van Word, ODF niet, dus OXML is uitgebreider. Of je dat als voordeel ziet ligt eraan.

Edit: Uitgebreider antwoord hier: http://en.wikipedia.org/w...and_Microsoft_XML_formats. Wel Wikipedia, dus over waarheidsgehalte valt te twisten.
Microsoft also states, relatedly to the previous point, that the OpenDocument format lacks support for the complete set of functionality in Microsoft Office applications (such as VBA and OLE support, support for highlighting[5], international numbering[6], tables in presentations[7], and other features), so any converter that saved information from an Office file (either binary or OpenXML) into an OpenDocument format would potentially be lossy.

Microsoft Excel has a well-known formula language that has been defined in its entirety in the new XML formats, whereas the OpenDocument TC is still working on such a specification. MS Office program manager Brian Jones notes on his Open XML blog that the Open XML draft specification has about 200 pages on the subject, whereas the OpenDocument specification has a few lines.[8]Currently ODF cannot be considered interoperable for spreadsheet documents as it allows for vendor specific implementations of the formulas in spreadsheets.
2 punten van de wiki-pagina die toch behoorlijk in het voordeel van Open XML uitpakken. Veel bedrijven hebben veel kritische "documenten" die volstaan met macro's, database-koppelingen e.d. als die niet goed gaan werken, of erger in het geval van het 2de punt, als die door een andere interpretatie van de formules het document of de database verminken.....
Functionaliteit (via de juiste wegen) aan ODF toevoegen lijkt me eenvoudiger dan zelf een helemaal nieuw formaat te ontwikkelen, ma bon, MS haalde dezelfde argumenten boven voor IE om anders met HTML om te gaan dan de andere browsers en we kennen het resultaat daar allemaal zo ongeveer van. Eerst zien en dan geloven.
Hoewel ik dat artikel wel enigzins ge-edit heb is het bepaalt nog geen goed artikel. Het is in feite een opsomming van punten door voorstanders van beide formaten. Bepaald geen objectieve meningen.

Helaas is er eigenlijk geen objectieve vergelijking beschikbaar en is die misschien ook wel niet te maken.

De doelstelling van OOXML is een open formaat met name geschikt voor MS Office en alle legacy documentatie en voor applicaties die gebruik willen maken van MS Office functionaliteiten. ODF heeft een bredere doelstelling. Dat heeft voordelen en nadelen. Zo is ODF minder afhankelijk van MS Office ontwikkeling maar dat is bijvoorbeeld voor veel applicaties nou juist een wens omdat veel producten juist aansluiting zoeken bij MS office.
En het is ook nog heel erg de vraag of ODF wel loskomt van zijn roots in OOo of dat het toch telkens OOo is die de ontwikkeling van dat formaat zal bepalen.

Op de korte termijn zal OOXML natuurlijk zeer snel marktaandeel veroveren. Op de langere termijn is het minder duidelijk maar dan spelen ook veel andere zaken een rol zoals de gehele ontwikkeling van ICT op de langere termijn.
Wat ik uit dit artikel kan halen is dat

OpenXML:
- veel afgekorte cryptische tags gebruikt.
- opmaak niet inline in de tekst staat (ala HTML), maar indirect gekoppeld wordt.
- voor alle functies (formules, meta-data, vector graphics) wordt het wiel overnieuw uitgevonden.

en in vergelijking is ODF:
- leesbaar
- herbruikt standaarden (DublinCore, MathML, SVG, XLink) tools kunnen deze sub-xml data uitlezen zonder ODF te begrijpen.
- eenvoudig om te zetten naar bijvoorbeeld XHTML.
- gebruikt altijd stijlen voor opmaak per paragraaf, niet per paragraaf herhaalde opmaak.

Welke van de twee formaten zal je het lieft willen omzetten (edit: met xsl of een script) naar HTML:
<text:span text:style-name="Strong_20_Emphasis"> this is bold </text:span>
(ODF)
<w:r><w:rPr><w:b /></w:rPr><w:t>this is bold</w:t></w:r>
(OpenXML)
Wel even vermelden dat dit artikel van de mensen achter ODF komt he :P

ODF hergebruikt de syntax en tags van oudere standaarden. MS heeft OpenXML vanaf de grond nieuw gebouwd omdat ze niet afhankelijk willen zijn van veranderingen in andere standaarden. Voor allebei valt iets te zeggen: ODF is makkelijker is voor mensen die de oude standaarden al kennen. OpenXML is wat consistenter.
voor alle functies (formules, meta-data, vector graphics) wordt het wiel overnieuw uitgevonden.
Ik dacht het niet:
Microsoft Excel has a well-known formula language that has been defined in its entirety in the new XML formats, whereas the OpenDocument TC is still working on such a specification
Lijkt er dus op dat ODF eerder het wiel opnieuw uitvindt, en OpenXML een bewezen oplossing implementeert.

En welke van de twee formaten ik om wil zetten? Als ik zo dom was om het met de hand te doen, de eerste, maar aangezien je dat automatiseert boeit dat niet echt. Bovendien vind ik 'makkelijk handmatig om te zetten naar HTML' niet echt een zwaarwegend voordeel.
@YaPP: Als je je script goed opbouwt zou het niet uit moeten maken wat de namen van de symbolen zijn.
ls ik zo dom was om het met de hand te doen, de eerste, maar aangezien je dat automatiseert boeit dat niet echt.
Met het omzetten refereerde ik ook naar het schrijven van een XSL of php-script waarmee je de XML omzet. In die gevallen blijft ODF door de eenvoudige structuur beter te verwerken.
<offtopic>
als die documenten in een XML achtige vorm worden opgeslagen, is het dan ook mogelijk om ze via XSLT om te zetten naar HTML of een andere XML-afgeleide?

ik zit nu word documenten om te zetten naar HTML en dat is niet echt leuk werk, het zou cool zijn als er eindelijk een goede manier was om ook ingewikkelde documenten om te zetten. (en dan niet die braggelle html export)
</offtopic>
Dat is dus met ODF een stuk makkelijker dan met OXML, maar het is met beide mogelijk.
Bij automatische convertie (zoals bijvoorbeeld xslt) is de html export maar zo slecht als het bronbestand, qua wellformed-heid
Voor mij is iets pas een echt open standaard als andere leveranciers op basis van de publiek beschikbare specificaties van die standaard een applicatie kunnen ontwikkelen die de bestanden die voldoen aan die open standaards kunnen inlezen, bewerkbaar zijn en bij opslaan weer zodanig zijn dat ze met de "originele applicatie" waar ze in gemaakt zijn weer te openen zijn alsof die andere applicatie er nooit aan te pas is gekomen. Ben benieuwd of dat met de specificaties die zometeen vrijgegeven worden van OpenXML mogelijk is, dus dat bv OpenOffice zodanig aangepast kan worden dat het OpenXML bestanden aan kan..
Dat kan straks met OpenXML. Uiteraard zal de ondersteunende toepassing (in jouw voorbeeld Open Office) dan wel de uitgebreidere functionaliteit van Microsoft Office moeten gaan ondersteunen. Maar als ze daaraan werken dan kan dat inderdaad. OpenXML is straks een ECMA standaard waar zowel Microsoft als andere partijen aan moeten voldoen.
Dus als ik het goed begrepen heb, dan kunnen alle overheden en organisaties nu gerust ademhalen als ze met open office of opensource werken. De documenten die ze in OXML maken zullen dan ook fatsoenlijk te openen en leesbaar zijn voor degene die dan nog MS Office gebruiken.
Vermoedelijk bedoel je precies het omgekeerde aangezien de meeste overheden en organisaties werken met MS Office.
Eigenlijk interesseert mij die hele OOXML vs. ODF discussie helemaal niet.
Waar het om gaat is dat de gebruiker nu eindelijk eens 1 OPEN standaard kan gebruiken op verschillenden platformen/editors zonder gezeik. Gaat die dag dan echt komen? :Y)
Voor een ieder die wat meer wil weten over OpenXML in het .NET Magazine nr 14 stond een mooi artikel waarin de structuur wordt uitgelegd en hoe simpel het is om tegen te programeren...

Zie:
http://www.microsoft.com/...zine/code/magazine14.aspx

Of voor het artikel:

http://download.microsoft...46c2f5af7/P31-35_1.21.pdf

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