The reason it's really not irrevocable is that it states in writing that future versions of anything under the promise are not automaticaly under the promise
Actually for Ecma standards this is ensured by Ecma International 'Code of conduct in patent matters' which requires contributors in technical committees and standard approval voters to license their patetns on RAND basis.
So only if Microsoft were to give up using an Ecma International or ISO standard alltogether and go back to a full propriety format they would not have grant patent licensing. This is a very unlikely scenario as new versions of Office would become unsellable if they would go from using a standard to a propriety format especially if they would stop using an ISO insternational standard format.
So actually the ISO standardization is a good lock in for MS Office to keep using an ISO standard format.
Office open XML is an Ecma International standard.
Ecma standards are ALL copyright free.
As for patents the Ecma members are required to give RAND licensing on every standard they participate in the TC (similar to OASIS) and in addition to that for each standard they vote to approve in Ecma.
So unless Microsoft starts objecting to 'their own' standard in Ecma, the Ecma rules guarantee that the Microsoft is required to continue to give RAND patent licensing for future ecma approved versions as well.
So rules for contributors are valid for Ecma standards as well as for OASIS standards. In Ecma however additional rules exist for 'approval' voters to release patents on approved astandards as well IBM was the only NO voter when Office Open XML was approved.
I am not so sure they are serious laywers.
If you look at the patent licensing by Sun (who contributed StarrOffice Patent Technology and IBM (that contributed Lotus patented technolgy) for ODF the same issues arise.
Specifically the IBM Interoperability Specifications Pledgehttp://www-03.ibm.com/linux/opensource/isplist.shtml is also only listing the versions it applies for (currently listing ODF v1.0 and ODF v1.1). Strangely the SFLC does not name this about the IBM licensing when making an analysis on ODF licensing but does name the version issue when reviewing Micrsofts OSP.
Also on their ODF license analysis the SLFC specifically mentions that OASIS rules on IP rights require participants in the standardization to RAND license those. However on the other hand the SLFC does not mention that Ecma International of which Office Open XML is an official standard requires all participant in their technical commitees AND ALSO all members that vote to approve a standard to RAND license their patents.
So on major issues the SFLC determines to ingnore information that are actually applies to both standards making their analysis on both OOXML but also their previous analysis on ODF very shaky and unreliable.
Apperantly a legal analysis by the SFLC is now no longer a legal analysis but a politics document and the opinion of the SFLC as a source of legal information will be a lot poorer after they make such biased choices on what to include and what not to include in their legal analysis based on what they want the outcome to be.
Or mayby even on how much money IBM is paying them to state this at this particular moment in time...
Please explain how a non-MS implementation of the OOXML standard will deal with those conforming files you were talking about when they contain VML blobs encoding proprietary Microsoft Ink data. The same as they would when the VML would be in a converted OOXML file where the VML in the format specification was ment for.
that no matter how things are encoded in ODF, it contains no proprietary technology whatsoever and it is therefore a much better format for interoperability and long-term archival. That however is incorrect. Actually ODF contains very propriety OLE linking and embedding technolgy (a Microsoft technology) and Java applet technology (a Sun technology) and it also contains arbitrary propriety technologies from each implementer in for instance the ODF propriety Office-setting features or contains propriety technology in extensions or in embedded binary or non-binary data.
Hmmm, in fact it totally resembles OOXML in that way except that OOXML has the propriety settings fully documented and ODF has not.
No, what I am saying is that the use of deprecated VML does not cause OOXML files to be non-interoprabel.
And you seem to have little understanding of the formats as ODF is actually a spec that is filled with binary base64encoded blobs elements.
[quote]at least the code to OpenOffice is available to inspection, making it possible for other vendors to actually implement it and get interoperability.[/quote]
So it isn't actually OpenDocument but OpenOffice document...
It is actually the ODF alliance response I would consider a joke. An anonymous response that looks to have been written by IBM (I even asked about that and IBM did not deny)
And on the charter of the OASIS TC for ODF. You do know that this TC was called the OpenOffice XML TC in its first two years and that it's goal was actually to develop a format to make the OpenOffice format more interoperable. Only after the EU asked them to submit the OpenOffice format to ISO they changed the name to OpenDocument (a term used in an EU rapport).
It's worse than that -- the MS-OOXML that Office saves documents in is not the same as the OOXML that MS spec'ed out to ECMA and got submitted to ISO.
You mean similar to OpenOffice.org that is not creating ODF files that match the ISO ODF spec or even not the 1.1 ODF spec or in fact not being fully compatible with any known ODF spec version (and never has been either).
The table thing is fixed in the latest ODF draft and in current applications.
That is actually not true.
Current applications do not use the latest draft. they use the ODF 1.1 version. A version never sumbmitted to ISO.
So actually most current application like OOo are not in line with the ISO specifications for ODF.
The latest draft in OASIS is a 1.2 draft version (it does actually fix the talbe issue) that has been severly delayed and is still not yet finished and it might take years still for it to become an ISO version looking at OASIS trackrecord on submitting new version to ISO.
Even though the VML behaviour in Office 2007 is not conforming it does not lead to OOXML files that are non conforming.
On the other hand there is evident information that ODF files created by OpenOffice.org are actually not conforming to the ODF specification because OpenOffice for instance uses a modified MathML 1.1 whereas ODF specifies that ODF files should be using w3c MathML 2.0.
http://idippedut.dk/post/2008/01/Do-your-math---ODF-and-MathML.aspx
If would seem that that MS Office 2007 is at least as good a representation of OOXML conformance as OOo 2.x is represnetation of ODF.
- Only ODF has multiple implementations by multiple vendors working on multiple platforms.
That is incorrect. For example OOXML has implementations on all major mobile platforms (Symbian, Palm OS, Windows Mobile and iPhone) and ODF doesn't.
Of course OOXML has also implementations on multiple desktop platforms and even in popular on line office suites like Thinkfree.
- Only OOXML has no implementations at all.
That is just laughable.
- Only ODF can be validated against a test suite.
There is indeed a test suite for ODF and it actually shows us that not a single implementation supports ODF fully or faithfully. That sure helps.
- Only ODF is truly open.
ODF is no more open than OOXML
- Only OOXML has "exclusions" in associated "promises not to sue".
Actually that is incorrect. Sun in their covenant not to sue has excluded any future version of ODF their have not contributed to significantly. If they do not agree with changes and leave the OASIS TC then their promise does not apply to new ODF versions anymore.
- Only OOXML is constrained via proprietary dependencies to run on just one platform.
That is actually incorrect. For instance ODF supports OLE linking and embedding.
- Only OOXML has failed at fast-track approval, and has 3500 as-yet-unresolved objections against it.
There were 3500 comments. However those do not contain 3500 unresolved objections as you suggest. About 3000 of those comments contain near identical copies of IBM objections that were spread amongst ISO members and found their way back in the comments making the number of unique comments less than 1000. Also most of the actual about 1000 issues in those comments are simple editorial issues and although you claim they are not resolved their is already a suggestion resolution by Ecma for nearly every comment.
Nice to use the open malaysia blog as a debunk. The guy behind that blog is clearly on the payroll of IBM.
This was very evident when Kenya send in their contradictions comments to ISO which were a combination of non-publicly available documents written by IBM Germany and the Open Malaysia blogger Yoon kit.
The Open Malaysia blog and the blog of Andy Uppgrove of the Linux foundation can only be seen as fronts for the IBM campaign as they seem to correlate each others blogposts and follow-up only on each others stories and of course each of their posts gets frontpage on IBM's sidekick blog Groklaw. I have a vivid recollection of Pamala Jones stating that she quoted IBM Rob Weirs blog on OOXML without her knowing he worked at IBM. Like that whole Groklaw site isn't totally geared to support IBM views and never manages to say anything bad about this patent claiming gigant and activly removes or blocks commenters that do.
If you make one file than any mistake or discussion on the reponse could lead to a entirly new document.
Having seprate documents is easy for the ballot resolution.
It can lead to a consensus where the original submitted text is amended with a (large) number of PDF's to be the result of the BRM and the National bodies can then vote on that set of reponses.
If the coments were in one document there would have to be a new document created with the reponses the BRM agreed on (removing all responses the BRM will not agree on). This might be trouwblesome seeing as there is very limited time after the BRM concludes to make a new version and redistribute it.
By using seperate documents the BRM meeting could on its conclusion have the original submitted text and a list of approved reponses ready by the end of the meet.
Rob Weir is indeed an employee from IBM known for his anti-ooxml blogposts.
And it seems his effort of spreading anti-ooxml information has now transgressed into the Google search engine.
Google apperantly refuses to index Office Open XML files.
See: http://ooxmlhoaxes.blogspot.com/2007/12/ooxml-google-search-engine-supports-ibm.html
Where Google indexes tons or arbitrary fileformats it manages to find only 1 percent of Office Open XML files on the web.
Regardless, I'd rather have a more limited format that's actually feasible to implement than "LineSpacingLikeWord95" bullshit. The compatibility features are much commented on but actually ODF has them as well. Only they made then more generic. ODF has generic Office setting that are fully implementation defined. At least in an OOXML file you will be able to recognize the compatibility setting in an ODF implementation it could be anything.
For instance OpenOffice uses the generic Office setting to define a setting called 'UseFormerLineSpacing'.
So in an OOXML file you can find something like:
<LineSpacingLikeWord95>
and in ODF you would find something like
<office-setting name="UseFormerLineSpacing">
The ODF solution is mayby a bit better looking because of it's generic presentation but it does not change much in the fact that the exact nature compatibility in both solutions is still not defined and if MS would have used this generic procedure I have little doubt we would also be discussing it here but then as an evil MS feature to hide the compatibility settings from other implementers. The solution provided by OOXML makes sure that MS does not hide any compatibility settings for anybody (like ODF settings do).
ODF does not use any office related open standard except for unicode.
For the rest it partially re-uses webstandards which were never intended for Office documents
That is just not comparable.
The DrawingML graphics support in Office Open XML for instance is a lot more extensive then the partial SVG + OpenOffice-3D-graphics support in ODF.
want a simple separation based on functional category No, you want both integration with the Office document and seperation.
That is why OMML can both incorporate other Office tags but also be converted to MathML with simple XLST conversion which also removes the integrated office xml information. (actual such XLST files are provided as seperate files with any Office 2007 installation)
So it is incredibly easy in Office Open XML to fully integrate OMML Math in the office document but also easy to copy and paste it out converted as MathML and vice versa.
It is a superieur solution. ODF uses an of the shelf format created for presenting Mathematical data on websites. OOXML creates a format that is both for presneting the mathmatical formula's but also for editting and revising then in an Office environment. This is something MathML just was not designed for.
This shows exactly the basic conceptand design difference of ODF and OOXML.
ODF is OpenOffice XML combined with W3C web XML. A little bit of both Office and Web.
OOXML is a more pure Office XML language combined with compatibility features for current Office documents.
There is something to say for both but they are not the same and not realy that interchangeable as might appear for the outsider.
If someone sends me a math formula to review then I would logically edit in the formula for correction or to add review notes to it. In ODF you would have to split the math formal in seprate math piecies for each edit/revision or review note added to the formula or effectivly anything done to the math formula.
[quote]My real concern remains misaddressed, which is that respect for de-jure standards are ignored while monopoly power leverages the introduction of what is likely to be a new set of conflicting and unnecessary (except for the purpose of maintaining said monopoly power) de-facto standards[/quote]
They weren't as much ignored as developed simultaniously.
It is a bit strange that if ODF was also ment to be a replacment for all Office documents including the 99% of document written in MS Office that nowhere in the ODF specifications was looked at the need for supporting existing MS Office functionality in the ODF specifcation or that noone from OASIS bothered to ask MS if they would donate their already existing XML specifications to aid in the developement of such a standard.
effectivly ODF was never developed to replace any MS Office documents. It is also never mentioned as a goal when developing the ODF specification and therefore is not adequate to do that.
On the other hand OOXML is developed with that backwards compatibility in mind. If does support all features used by the application most Office users are currently using.
If ODF was ever ment to replace MS Office document then they should stated that as a goal of the format right from the start and they should have had Microsoft on board in the development of such a format because there would have been no point in developing a format with such a goal without the help of MS.
When was that? MS had their first XML based format in use in 2000 in the beta of Office XP.
I do remember hearing about an XML-based format a very long time ago, but it had large binary blobs, which makes it exactly as much XML as the following blockquote is, Then you will be happy to know that for instance ODF still supports binary blobs in it's XML.
Mayby OASIS isn't listing that as a main feature though...
So why didn't they extend it? Actually you can't extend ODF that easily. For instance Office Open XML math (OMML) can combine office document tags in amonst the math tags. So you can use footnotes or revision tags in OMML.
ODF uses external MathML which comes from W3C but included in ODF cannot be mixed with other office document tags. So to extend ODF you would either have to add all of OMML to ODF or to change the w3c MathML standard.
And that is just one example. It would require more extending than is originally in the ODF spec to accomodate the needs of MS Office.
Also the container of ODF is just less good than the Open Convention Packaging used by Office Open XML and that is actually not extendable in the ODF spec.
D) Because the EU asked Microsoft to standardise their Office document format at a standards organisation Citation? http://ec.europa.eu/idabc/en/document/2592/5588
Microsoft should consider the merits of submitting XML formats to an international standards body of their choice;
For us geekier than finance types, dumping mathML for Office Math Markup Language OMML, and SVG for DrawingML is what hurts! Firstly OMML is more usefull than MathML for Office documents because it can combine Office document features like revision ID's or footnotes with the Math XML. ODF that uses MathML cannot mix other Office document tagging within MathML document parts.
Secondly OMML can be easily converted by simple XLST transformation to MathML (of course you then loose any additional Office tags included in the math) and back
Thirdly ODF does not use SVG either. ODF only uses a limited SVG subset with it's own ODF namespaces and also adds additional propriety OOo related graphical 3D drawing tags.
Fourthly DrawingML support is much more extensive than the SVG subset ODF uses. It is for instance possible (allthough not required) for SVG images to be converted into native DrawingML items in the OOXML documents. MS Office 2007 for instance does this. This is virtually impossible with SVG in ODF. Because ODF-SVG is smaller than SVG you will normally only embed SVG items as seperate embedded files in an ODF archive and not as native SVG code in the actual document file.
Slashdot Mirror
On the other hand: ODF was put trough ISO in 5,5 months OOXML took more than 15 months
ODF 1.0 has many defects as well and OASIS is only now trying to correct them several years after submitting the standard to ISO.
Actually for Ecma standards this is ensured by Ecma International 'Code of conduct in patent matters' which requires contributors in technical committees and standard approval voters to license their patetns on RAND basis.
So only if Microsoft were to give up using an Ecma International or ISO standard alltogether and go back to a full propriety format they would not have grant patent licensing. This is a very unlikely scenario as new versions of Office would become unsellable if they would go from using a standard to a propriety format especially if they would stop using an ISO insternational standard format.
So actually the ISO standardization is a good lock in for MS Office to keep using an ISO standard format.
Office open XML is an Ecma International standard.
Ecma standards are ALL copyright free.
As for patents the Ecma members are required to give RAND licensing on every standard they participate in the TC (similar to OASIS) and in addition to that for each standard they vote to approve in Ecma. So unless Microsoft starts objecting to 'their own' standard in Ecma, the Ecma rules guarantee that the Microsoft is required to continue to give RAND patent licensing for future ecma approved versions as well.
So rules for contributors are valid for Ecma standards as well as for OASIS standards. In Ecma however additional rules exist for 'approval' voters to release patents on approved astandards as well IBM was the only NO voter when Office Open XML was approved.
Specifically the IBM Interoperability Specifications Pledgehttp://www-03.ibm.com/linux/opensource/isplist.shtml is also only listing the versions it applies for (currently listing ODF v1.0 and ODF v1.1). Strangely the SFLC does not name this about the IBM licensing when making an analysis on ODF licensing but does name the version issue when reviewing Micrsofts OSP.
Also on their ODF license analysis the SLFC specifically mentions that OASIS rules on IP rights require participants in the standardization to RAND license those. However on the other hand the SLFC does not mention that Ecma International of which Office Open XML is an official standard requires all participant in their technical commitees AND ALSO all members that vote to approve a standard to RAND license their patents.
So on major issues the SFLC determines to ingnore information that are actually applies to both standards making their analysis on both OOXML but also their previous analysis on ODF very shaky and unreliable.
Apperantly a legal analysis by the SFLC is now no longer a legal analysis but a politics document and the opinion of the SFLC as a source of legal information will be a lot poorer after they make such biased choices on what to include and what not to include in their legal analysis based on what they want the outcome to be.
Or mayby even on how much money IBM is paying them to state this at this particular moment in time...
I'll copy a XML schema part from the ODF specification paragraph 9.3.3
A nice combination of the OLE objects and the binary blob together in ODF.I guess the ODF propaganda machine forgot to mention this part?
Enjoy.
No, what I am saying is that the use of deprecated VML does not cause OOXML files to be non-interoprabel. And you seem to have little understanding of the formats as ODF is actually a spec that is filled with binary base64encoded blobs elements.
[quote]at least the code to OpenOffice is available to inspection, making it possible for other vendors to actually implement it and get interoperability.[/quote] So it isn't actually OpenDocument but OpenOffice document...
It is actually the ODF alliance response I would consider a joke. An anonymous response that looks to have been written by IBM (I even asked about that and IBM did not deny) And on the charter of the OASIS TC for ODF. You do know that this TC was called the OpenOffice XML TC in its first two years and that it's goal was actually to develop a format to make the OpenOffice format more interoperable. Only after the EU asked them to submit the OpenOffice format to ISO they changed the name to OpenDocument (a term used in an EU rapport).
The latest draft in OASIS is a 1.2 draft version (it does actually fix the talbe issue) that has been severly delayed and is still not yet finished and it might take years still for it to become an ISO version looking at OASIS trackrecord on submitting new version to ISO.
On the other hand there is evident information that ODF files created by OpenOffice.org are actually not conforming to the ODF specification because OpenOffice for instance uses a modified MathML 1.1 whereas ODF specifies that ODF files should be using w3c MathML 2.0. http://idippedut.dk/post/2008/01/Do-your-math---ODF-and-MathML.aspx
If would seem that that MS Office 2007 is at least as good a representation of OOXML conformance as OOo 2.x is represnetation of ODF.
- Only ODF has multiple implementations by multiple vendors working on multiple platforms. That is incorrect. For example OOXML has implementations on all major mobile platforms (Symbian, Palm OS, Windows Mobile and iPhone) and ODF doesn't. Of course OOXML has also implementations on multiple desktop platforms and even in popular on line office suites like Thinkfree. - Only OOXML has no implementations at all. That is just laughable. - Only ODF can be validated against a test suite. There is indeed a test suite for ODF and it actually shows us that not a single implementation supports ODF fully or faithfully. That sure helps. - Only ODF is truly open. ODF is no more open than OOXML - Only OOXML has "exclusions" in associated "promises not to sue". Actually that is incorrect. Sun in their covenant not to sue has excluded any future version of ODF their have not contributed to significantly. If they do not agree with changes and leave the OASIS TC then their promise does not apply to new ODF versions anymore. - Only OOXML is constrained via proprietary dependencies to run on just one platform. That is actually incorrect. For instance ODF supports OLE linking and embedding. - Only OOXML has failed at fast-track approval, and has 3500 as-yet-unresolved objections against it. There were 3500 comments. However those do not contain 3500 unresolved objections as you suggest. About 3000 of those comments contain near identical copies of IBM objections that were spread amongst ISO members and found their way back in the comments making the number of unique comments less than 1000. Also most of the actual about 1000 issues in those comments are simple editorial issues and although you claim they are not resolved their is already a suggestion resolution by Ecma for nearly every comment.
Just because IBM and the ODF alliance (IBM's propaganda channel on ODF) say the rapport is inaccurate it does not have to be. The Burton group has responded to these allegations in several instances: http://ccsblog.burtongroup.com/collaboration_and_content/2008/02/burton-groups-r.html http://ccsblog.burtongroup.com/collaboration_and_content/2008/02/burton-groups-1.html http://ccsblog.burtongroup.com/collaboration_and_content/2008/02/burton-groups-2.html
Nice to use the open malaysia blog as a debunk. The guy behind that blog is clearly on the payroll of IBM. This was very evident when Kenya send in their contradictions comments to ISO which were a combination of non-publicly available documents written by IBM Germany and the Open Malaysia blogger Yoon kit. The Open Malaysia blog and the blog of Andy Uppgrove of the Linux foundation can only be seen as fronts for the IBM campaign as they seem to correlate each others blogposts and follow-up only on each others stories and of course each of their posts gets frontpage on IBM's sidekick blog Groklaw. I have a vivid recollection of Pamala Jones stating that she quoted IBM Rob Weirs blog on OOXML without her knowing he worked at IBM. Like that whole Groklaw site isn't totally geared to support IBM views and never manages to say anything bad about this patent claiming gigant and activly removes or blocks commenters that do.
If you make one file than any mistake or discussion on the reponse could lead to a entirly new document. Having seprate documents is easy for the ballot resolution. It can lead to a consensus where the original submitted text is amended with a (large) number of PDF's to be the result of the BRM and the National bodies can then vote on that set of reponses. If the coments were in one document there would have to be a new document created with the reponses the BRM agreed on (removing all responses the BRM will not agree on). This might be trouwblesome seeing as there is very limited time after the BRM concludes to make a new version and redistribute it. By using seperate documents the BRM meeting could on its conclusion have the original submitted text and a list of approved reponses ready by the end of the meet.
Rob Weir is indeed an employee from IBM known for his anti-ooxml blogposts. And it seems his effort of spreading anti-ooxml information has now transgressed into the Google search engine. Google apperantly refuses to index Office Open XML files. See: http://ooxmlhoaxes.blogspot.com/2007/12/ooxml-google-search-engine-supports-ibm.html Where Google indexes tons or arbitrary fileformats it manages to find only 1 percent of Office Open XML files on the web.
and in ODF you would find something like
The ODF solution is mayby a bit better looking because of it's generic presentation but it does not change much in the fact that the exact nature compatibility in both solutions is still not defined and if MS would have used this generic procedure I have little doubt we would also be discussing it here but then as an evil MS feature to hide the compatibility settings from other implementers. The solution provided by OOXML makes sure that MS does not hide any compatibility settings for anybody (like ODF settings do).
ODF does not use any office related open standard except for unicode. For the rest it partially re-uses webstandards which were never intended for Office documents That is just not comparable. The DrawingML graphics support in Office Open XML for instance is a lot more extensive then the partial SVG + OpenOffice-3D-graphics support in ODF.
This shows exactly the basic conceptand design difference of ODF and OOXML.
ODF is OpenOffice XML combined with W3C web XML. A little bit of both Office and Web.
OOXML is a more pure Office XML language combined with compatibility features for current Office documents.
There is something to say for both but they are not the same and not realy that interchangeable as might appear for the outsider.
If ODF was ever ment to replace MS Office document then they should stated that as a goal of the format right from the start and they should have had Microsoft on board in the development of such a format because there would have been no point in developing a format with such a goal without the help of MS.
Secondly OMML can be easily converted by simple XLST transformation to MathML (of course you then loose any additional Office tags included in the math) and back
Thirdly ODF does not use SVG either. ODF only uses a limited SVG subset with it's own ODF namespaces and also adds additional propriety OOo related graphical 3D drawing tags.
Fourthly DrawingML support is much more extensive than the SVG subset ODF uses. It is for instance possible (allthough not required) for SVG images to be converted into native DrawingML items in the OOXML documents. MS Office 2007 for instance does this. This is virtually impossible with SVG in ODF. Because ODF-SVG is smaller than SVG you will normally only embed SVG items as seperate embedded files in an ODF archive and not as native SVG code in the actual document file.