ODF Editor Says ODF Loses If OOXML Does 268
An anonymous reader writes "The editor of the Open Document Format standard has written a letter (PDF) that strongly supports recognizing Microsoft's OOXML file format as a standard, arguing that if it fails, ODF will suffer. 'As the editor of OpenDocument, I want to promote OpenDocument, extol its features, urge the widest use of it as possible, none of which is accomplished by the anti-OpenXML position in ISO,' Patrick Durusau wrote. 'The bottom line is that OpenDocument, among others, will lose if OpenXML loses... Passage of OpenXML in ISO is going to benefit OpenDocument as much as anyone else.'"
3 questions... (Score:5, Insightful)
He invoques the need to have a formal definition of some features (formula definitions and legacy stuff) as benifiting ODF if OOXML pass, so this raises the questions:
1) Aren't these already included to some extend in what was submitted for iso acceptation?
2) Wasn't this specification part of what EU's justice were asking Microsoft anyways?
3) Is it that hard to reverse-ingeneer that kind of spec?
Asking in good faith, as I really hav no clue.
Don't fully understand his arguments (Score:5, Insightful)
Okay, now I'm'a *hafta* RTFA... (Score:5, Insightful)
... at least so I can find out what he's smokin' and get me some of that. I mean, whah??? If OOOXML is garbage, and not an open standard given the really big implementation holes, and not apparently implemented *anywhere* (nor, some might argue, implement*able*), why is it in anyone's interest to have it passed? Aside from Microsoft's, of course.
Confused,
Re:3 questions... (Score:5, Insightful)
No. His point seems to be that some features are not in ODF yet, so we might as well accept Microsoft's, and that way we have to support fewer different implementations of features. He's approaching this thing with a naivete that is stunning in an adult who has watched Microsoft's behavior with standards.
From the letter:
More importantly, what if ISO and Microsoft reach different definitions for the same OpenXML functions? After watching Java and Kerberos and CSS... We already have indications that Microsoft would ignore ISO on OOXML, too.
Ka Ching (Score:3, Insightful)
Well, I disagree. (Score:5, Insightful)
I don't know about ODF (Score:5, Insightful)
The only thing is, 500 pages of ODF spec may not be much better for small businesses. What we need is a specification with multiple levels of fallback for simplier generators and consumers. For example, one part of a document zip file can be plain text contained in the document, with reasonable efforts to convert document structure to a human and machine readable plain text representation. For producers, it will be valid to generate a document bundle with only the text file and nothing else.
Despair (Score:3, Insightful)
I despair at the behaviour and apparent quality of technical expertise of some of my peers.
Re:ODF editor on OOXML (Score:5, Insightful)
Yeah, that's what we call "not documenting the format."
Oh, and yeah, great, they documented the format. But it is NOT something that should be accepted as a standard. BF is a documented programming language, but if you had to pick a standard language, would you pick BF, if there was, oh, any other alternative?
What is so difficult about the two words "open" and "standard"? A proprietary trade secret is antithetical to that. Relying on proprietary trade secrets in a proposed "open standard" makes it neither.
Which in no way mandates that these legacy attributes also be completely opaque to every implementation except one.
Oh, by the way, we have a way to store odd formatting, and maintain backwards translateability -- styles. Extend the style system to where it can support weird shit like adjusting the "justify" algorithm, and store a SpacingLikeWordPerfectForDos (or whatever) style, in the document, with some special flag to indicate how it translates back into legacy formats (like Word 95 binary .doc).
Except that, as you say, the cryptic legacy stuff is a trade secret. Which is why we really don't want it ratified as any kind of open standard, as it is, quite simply, not open.
I'm sorry, but you can't have it both ways. Either you've got trade secrets based on your file format, or you have an open standard. Not both.
no "co-evolution" (Score:5, Insightful)
It's an office format, not nuclear fusion reactor design. ODF is already the better format, and there's nothing that ODF can learn from OOXML. Whatever expertise might flow from other standards into ODF already does because ODF (unlike OOXML) builds on existing standards.
But there's another reason why ODF won't benefit: OOXML "standardization" is just a trophy to Microsoft, a check-list item for buyers who want a standardized, open document format. Microsoft is going to keep adding proprietary extensions as they see fit, without bothering going through standardization or documenting them.
(The guy also grossly misuses the term "co-evolution", but let's not dwell on that.)
That may be true, but... (Score:5, Insightful)
* There are some serious technical issues with the current proposal that have to be resolved
* There are some very serious problems with the way the process has evolved
* There is no guarantee that Microsoft will follow their own standards -- since, if there are big changes to the standard, it would require them to change their current file format.
The first two problems indicate that, perhaps, the fast-track-to-ISO was not a good idea for this standard, and that some more time and work is required before the standard is approved, no matter how beneficial an eventual approval would be for anyone.
Re:We failed already (Score:5, Insightful)
Acrobat, on the other hand, is a bloated pile of garbage.
Re:We failed already (Score:5, Insightful)
Re:Don't fully understand his arguments (Score:5, Insightful)
Re:Well, I disagree. (Score:3, Insightful)
Re:3 questions... (Score:5, Insightful)
That being said, I don't think people want ODF to be a magic bullet, and everyone knows that ODF is feature thin compared to OOXML. However, I think after decades of shifting vendor to vendor as corporate interests take turns in the gang-raping that has been the software industry for as long as I can remember, people have realised that open standards are better than extra features, provided that the basics are covered. That, to me sums up the ODF vs OOXML debate; format stability vs edge case features.
Even at their worst, they are good (Score:3, Insightful)
Re:Okay, now I'm'a *hafta* RTFA... (Score:4, Insightful)
Governments increasingly demand software that supports open document standards. Because they finally realize the problems vendor lock-in can give them. That means that Microsoft's OOXML has at least to look like an open standard.
If it doesn't, MS is faced with two unpleasant alternatives:
1) Rework Office to support ODF. In this case, they would lose vendor lock-in and they would also have to catch up to the implementations of others. For a few years, I guess Open Office would look a lot better than MS office because they have a head start with ODF.
2) Lose the government business, leading to companies who work a lot with the authorities also switching for compatibility. Another great way to erase the dominant position of MS Office
Another view from the OASIS ODF TC (Score:3, Insightful)
Of course, he is entitled to express his personal views. And so am I.
Let us begin.
Patrick makes 5 assertions in his letter, and these are easily rebutted:
1) National bodies lose an open and international forum for further work on DIS 29500.
*Is Patrick implying that Ecma is not open and international? That would be a good thing to to know in those places where Microsoft is currently pushing for adoption of OOXML, arguing that it is an open standard.
One does not approve a standard in ISO in order to be more open. Openness should be there from the beginning. Patrick's argument appears to be
"Let's give OOXML the highest level of approval and then it will be a better standard". But ISO standardization is not done with sacramental
oils. There is not transmutation. OOXML does not become a good standard because it is approved. A standard is approved because it is good.
2) Microsoft based third-party vendors may be excluded from contracts because Microsoft has no ISO approved format.
*Microsoft could always add support for ODF to their product. Then they would be supporting an ISO standard. Similarly, I assume they are now seriously thinking of adding Blu-ray support to the XBox now that HD DVD failed. We should not be propping up Microsoft and giving them a free ticket to ISO because of their bad business decision in ignoring ODF and delaying their own standardization activities. The market rewards those who guess right, and punishes those that guess wrong. Microsoft was on the wrong side of open standards. We should not be looking to avoid the natural outcome of that.
3) ODF has no ISO-based formula definitions to insure compatibility between OpenDocument and OpenXML.
*And OOXML has no ISO-based formula definitions either, because OOXML has not been approved by ISO!
4) ODF has no ISO-based definition of MS legacy features for an ODF extension.
*And OOXML has no ISO-based definition of MS legacy features either, because OOXML has not been approved by ISO!
5) ODF has no ISO-based definition of the current MS format for mapping purposes
*And OOXML has no ISO-based definition of the current MS format either, because OOXML has not been approved by ISO!
These last three points by Patrick are rather poor. The fact that portions of the Ecma-376 specification are interesting as technical disclosures of proprietary Microsoft Office interfaces does not automatically recommend the entire 6,045 page specification for approval as an ISO standard. If the ODF TC desires any information on these three topics, we already have access to all of this material via the Ecma-376 text and the Ecma's Disposition of Comments report, both of which will exist regardless of whether DIS 29500 is approved. There is absolutely nothing we cannot do now, given the materials we have now.
Whether things like the spreadsheet definitions in OOXML are "ISO-approved" or not is immaterial. We know the ISO review was shallow. We cannot assume that Excel compatibility information in OOXML is correct. We need to test and verify everything. Slapping an "ISO" label on OOXML doesn't make it more useful or more accurate for ODF.
In no way whatsoever is ODF hurt, harmed or even annoyed by the imminent demise of Microsoft's ill-conceived and reckless experiment in ISO.
Have YOU used acrobat? (Score:3, Insightful)
Patrick Who? (Score:3, Insightful)
Because you don't know the remit of the standard (Score:1, Insightful)
But that isn't all that's needed.
How do you store tracking information? How do you store equations? How do you store an index? How do you make links that will change? Line drawings?
When you've done all that to XHTML, you've now included MathML, SVG, PNG,
And then you'll have to submit this collected standard to a standards body, get it checked and tweaked for any errors or omissions you've made.
And you know what? That's what ODF has done.
ODF *is* what you'd get if you did what you asked for.
Take this as you want (Score:2, Insightful)
Re:I don't know about ODF (Score:4, Insightful)
Re: 3 questions... (Score:3, Insightful)
Thus, the consequence is essentially that Windows clients need to use a Windows server for getting tickets, which, I would argue, was precisely their intention in doing so. That way, they can lock out non-Microsoft products from the servers, where they don't have a strong market lock-in, and still claim interoperability since non-Microsoft clients can still use Windows servers for authentication. I don't think that's just a coincidence resulting from the best possible technical implementation of their authentication protocol, especially seeing how the vendor-specific data could just as well be put in the LDAP directory instead (at least as I've understood it, it's just information on what groups the principal is a member of).
Microsoft may well not have violated the standard, but saying that what they did is perfectly alright, is a bit like saying that it's OK to murder people on the moon, just because there's no law enforcement there. And, especially seeing how it's Microsoft, I would be surprised if it were not part of an orchestrated effort, rather than just a small technical glitch.
I don't know any details about the mentioned problems with Java and CSS, but I would not at all be surprised to find the same thing there, as well.