To read all comments associated with this story, please click here.
Well ODF spent 4 years at OASIS before being submitted. And then when it was submitted the limitations of the proposal were documented. A specification does not have to cover every eventuality. However what the specification does cover should be clear and allow for an implementation (in terms of compliance) to be created based on the specification alone. Writing a specification and saying that part X "should match this specific legacy app" is not only insufficient but sloppy.
Edited 2007-09-04 22:06
A format doesn't have to have all kind of functionality. A standard will always have weaknesses. And that's okay. That's why standards are updated from time to time.
What an open standard cannot have is dependencies on proprietary technologies. Especially unspecified proprietary technologies.
The fact that a standard have technical issues is not a reason to disapprove the standard - as long as the format is fully specified. A fully specified format doesn't have to have all kind of functionality. What functionality it DOES have MUST however be documented. ODF is fully documented, but have some weaknesses. OOXML is not fully documented, since parts of it is unspecified. Therefore it has been rejected.
QUOTE
What an open standard cannot have is dependencies on proprietary technologies. Especially unspecified proprietary technologies.
UNQUOTE
Well said..........
I totally agree with you here....
So I hope that the standards body will keep this in mind.
I think the FSF must start a campaign as well because you can expect MS to do the same. Countries that voted yes should be influenced to vote no. Especially the countries that have done this in a suspicious way.
I can't say for sure, but I'll venture that it's because it aims at being a true portable standard, and not one that tries to incorporate all kinds of legacy MS cruft, which is what OOXML does (legacy support should be handled by *applications*, not file formats).
ODF may have been incomplete in some ways (though that is matter to debate), but it was designed from the ground up to be truly platform-neutral.
MS is already trying to spin this in a positive light, saying that a majority of participants voted yes, and that this indicates that its chances of being accepted after the "regular" process are good, but make no mistake: this is a slap in the face for MS, and seriously hampers their underhanded efforts to retain control of the "standard" office file format (and thus, of the desktop).
This is a good day for ODF supporters.
Basically, no format as encompassing as an office suite format should be approved the first time around for iso status on the fast-track process. If it is, something is wrong.
ODF did not go through the "fast track" process. It went through the "Publicly Available Specification" (PAS) rules.
This is the story for ODF:
http://en.wikipedia.org/wiki/Opendocument#Standardization
After a six-month review period, on May 3, 2006 OpenDocument unanimously passed its six-month DIS ballot in JTC1, with broad participation, after which the OpenDocument specification was "approved for release as an ISO and IEC International Standard" under the name ISO/IEC 26300:2006.
After responding to all written ballot comments, and a 30-day default ballot, the OpenDocument International Standard went to publication in ISO, officially published November 30, 2006.
It is a story of consensus and iterative development resulting in a collaborative work, rather than a story of manipulation and pushing and corruption and ballot-stuffing.
This is why ODF passed through ultimately with no "NO" votes.
Edited 2007-09-04 23:24
When it comes to specifications, the standard has to be at least as large as it needs to be, and not one page shorter. Larger is usually better, especially when there's more room for explanation (and less room for uncertainty).
Ever browsed the POSIX standard or the C definition, or the Java specification?
"It's easier to read 600 pages as opposed to reading 6000 pages."
This is true, but I read yesterday that the Java spec had 8000 pages.
http://www.infoworld.com/article/07/08/28/Retired-Ecma-chief-expect...
"Regarding objections to the Open XML application because of its length, Van Den Beld said that when Sun Microsystems submitted the Java programming language to ECMA in 1999, the application -- which was eventually withdrawn -- was more than 8,000 pages long."
Also, the OOXML spec actually used a larger font than is standard practice, which increases the number of pages, and has lots of tutorial documentation.
http://www.oreillynet.com/xml/blog/2007/08/last_days_for_office_ope...
"Behind the scenes, Patrick Durusau (the ISO ODF editor) has been working on a really interesting and useful project. While he is not keen that people use ISO Open XML, he is keen that the quality of ISO standards should be maintained and he sees OOXML as a way to get MS’ technical requirements on the table to help future ODF improvement (whether by cherry-picking, mix-n-match or knowing what to avoid.) I suggested to him a time ago that one approach to fixing DIS 29500 would be radical surgery: removing all the explanatory and non-normative material. At the moment it is far too tutorial. That is fine for the Ecma version, but gets in the way of an ISO-quality standard. I had also suggested that the schema fragments were otiose too, and that the 11pt body text should be 10 pt. . So Patrick has gone ahead and stripped out the fluff from the WordprocessingML chapter and with tighter formatting he was able to go from 1874 pages to 607 pages without altering the technical content!"
So it may be that during the next phase, they'll use 10pt font rather than 11pt, and remove all of the tutorial material (which would become a supplementary document, but not part of the spec itself). That would address the complaints about "too many pages!"
Edited 2007-09-05 01:05
Part of why ODF was accepted is simply that very few people cared about it at all.
If it had gone under the same scrutiny as MS OOXML have been put under, chances are that the number of comments would have been a lot more. That's not to say that it wouldn't be accepted though, as it reportedly didn't go through "fast-track".
If it had gone under the same scrutiny as MS OOXML have been put under, chances are that the number of comments would have been a lot more. That's not to say that it wouldn't be accepted though, as it reportedly didn't go through "fast-track".
This comment does not bear any relation to reality.
ODF went through a far greater scrutiny than MS OOXML. The ODF approval path took 4 years.
http://en.wikipedia.org/wiki/Opendocument#Standardization
Unanimous.
ODF indeed did not go through a "fast track" process ... it went through a far more thorough and far longer process than that. (PAS process).
Microsoft sat in on the development of ODF. If Microsoft had any issue with what ODF did or did not support, or how it was supported, then they sat mute for a long, long time about it.
Still, even now, if Microsoft wants something added to ODF so that the world can come to an agreed open format consensus, then let Microsoft just speak up as per the French suggestion of a merged standard and any such problem is solved.
Edited 2007-09-05 07:23








Member since:
2005-07-06
As it should be.
Though I'm kind of curious why ODF wasn't rejected "with comments" as well, as it has it's own share of technical issues. Why couldn't they do that for ODF as well so the technical issues could be addressed, giving plenty of time for it to be approved on the "fast track" process.
Basically, no format as encompassing as an office suite format should be approved the first time around for iso status on the fast-track process. If it is, something is wrong.