Slashdot Mirror
ODF Editor Says ODF Loses If OOXML Does
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.'"
Okay, I Am Not An Iso-standard Expert (IANAIE ?), but that must be the most counter-intuitive argumentation I've heard this month.
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 take my posts literally; it's just code to control my botnet.
He seems to hinge everything on the assumption that Microsoft is going to follow whatever version on OOXML is adopted, allowing ODF to be able to port those features. I think that's a huge assumption on his part.
"Thanks for all the money you paid to us. We've used it to buy off ISO among other things" -Microsoft
pdf of letter
"Thanks for all the money you paid to us. We've used it to buy off ISO among other things" -Microsoft
... 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,
"What in the name of Fats Waller is that?"
"A four-foot prune."
when the letter has to be distributed in PDF.
Me thinks the bottom line he mentioned was under his own bank balance. Ive heard Microsoft has soft pillows in its bed.
"Persistance is Fertile" - Me. I can quote myself if I want to.
The majority of publications are in defense on OOXML. As the editor, I would expect the majority of his publications to be about weakness in OpenDocument and how it can be improved. I am curious as to his opinion on how to competing document standards can coexist -- what's the point of OpenDocument if only 5% of people user it. And the other 95% use OOXML, in that case, OpenDocument is a total waste of time.
"Thanks for all the money you paid to us. We've used it to buy off ISO among other things" -Microsoft
http://www.robweir.com/blog/2008/03/contra-durusau-part-1.html
on his blog for more details.
http://www.robweir.com/blog/2008/03/contra-durusau-part-1.html
This guy Durusau seems to have changed his mind to a pro-MS shill in recent times.
If you keep throwing chairs, one day you'll break windows....
Why is this marked troll?
Should be like, +2 funny
I do not support any "standard" that is bad enough that its own promoters have to buy votes to get it in.
This is conjecture, obviously, but I find it plausible, FWIW, especially since there is now a follow-up.
What I don't understand is why he doesn't see the elephant in the room: OOXML would be a giant competitor as an ISO standard! How does he think OOXML and ODF are going to supported in MS Office? Equally?
Without OOXML as an ISO standard, ODF would be the preferred choice for exchangeable documents. With OOXML as an ISO standard, OOXML would be (for the average company/user).
But if OOXML passes, customers, small to medium businesses and even world's governments are going to suffer. It's impossible for a team of 10 developers to implement a 1000+ page specification in their product. And because of ambiguities in the same, citizens will not be able to understand laws or government budgets of their own land.
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.
Has the Amazing Kreskin confirmed this??
Take the cheese to sickbay, the doctor should see it as soon as possible - B'Elanna Torres, "Learning Curve"
Using PDF when he could have forced the entire world to install OOo to read it in ODF format.
Deleted
...it's obvious that ODF loses if OOXML loses.
:-(
MS will use it's pawns in the various technical committes to crush any proposed beneficial changes to ODF, and probably push through some bad ones, so that ODF becomes increasingly marginalised.
Ah, if only there were [sarcasm] tags around that...
That post by Rob is particularly good, I recommend it.
In addition,
Patrick Durusau is one of several editors on ODF (in ODF 1.0 he was one of six editors) and in ODF 1.1 and the 1.2 drafts he's one of three and one of two respectively. So he's not the editor, he's an editor.
Patrick doesn't present technical arguments, he only presents political ones, and generally he seems to be of the opinion that it's better that Microsoft be involved in ISO than not (and this opinion overrides any issues of quality, or whether anyone else can implement OOXML). This is the idea that this way we get to have more of an impact on Microsoft.
In my opinion OOXML is an insincere involvement in the ISO process (as shown by minimum change during the fast-track, and poor documentation of OOXML) and I think it's naive to expect more in the future. So to me the political angle on this fails.
The technical angle on it fails completely.
Technical issues aside. We all lose if we bow to corruption too.
I despair at the behaviour and apparent quality of technical expertise of some of my peers.
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.
Don't thank God, thank a doctor!
I'm gonna repost this comment from another ooxml "sudden flipflop" story - I posted it too late to get any attention then but I still wanted it visible. AC for obvious reasons! Also please bear in mind that all numbers are just for example's sake, but the general point is all too accurate. Also bear in mind I have no "inside" information on Durusau at all, I am just trying to tell you some backstory on how these deals can go down, including one I have specific knowledge of.
-------
I want to tell you Slashdot people something about how this kind of thing works. I don't really know the name for it, but I call it "soft bribery". You might also call it "economic alignment" or whatever. Here's what happens.
A large, rich stakeholder wants a particular outcome - in this case, MS wants OOXML to be ratified. They have some adversaries - respected leaders of the OSS movement or ODF foundation, in this case. Note that there are always certain people with disproportionate voices - these people are really hurting them. How can they turn them around?
They can't outright bribe them. That's illegal and probably wouldn't work anyway - people would feel insulted. So what they need to do is ensure that the "thought leader"'s economic interest is aligned with their own.
We see this happen all the time - a previous strong advocate against something, in this case pro ODF and against OOXML, will suddenly get more concilatory. See Durusau's change of tone for an example. Now I don't know him, but I'm pretty sure here's what happened.
He would be in constant contact with the OOXML team in MS just as a matter of course. One day, though, they'll tell him to expect a call from a VP or higher - big guns. He's excited to be able to reach higher up in the company. Finally, they're taking him seriously. He might be talking to a billionaire!
He'll get the call. "Wow, we're really impressed with your work on this. My team is always telling me what a smart, together guy you are", says the VP or Partner or whatever. "I just wanted to tell you that we really appreciate the work you're doing and we can learn a lot from you. Say, when this is all over, if OOXML finally gets accepted - we'd love to get you in for some interoperability training and consulting, our staff could really use your insight. We pay pretty well, $500 an hour, and we estimate the contract would last for a year fulltime, but we're flexible with your current work - we just need you on call. What do you think?"
There you go. That's it. A year's worth at $500/hr is close enough to a million bucks, the guy's got a mortgage, game over. Of course MS wants it kept quiet or the deal's off - that's their "standard business practise", and the contract has an NDA clause.
Game over. I'm sure this is what happened to Durusau. I'm pretty sure it's what happened to Miguel. Unless you're independently wealthy, not many people can say no to a few hundred thousand in "consulting". Needless to say, he'll never step foot in any Microsoft building. Hell, maybe it's a lot less than a million - it was for someone I know.
I am going to be very vague here - sorry if you think I lose credibility, but I don't want to burn my friend. He was the CEO/CTO (same guy) at a small systems integrator in the educational sector "somewhere in Asia". A largish school deal was in the works, his company advised decision makers in favour of linux. A respected company, had a lot of sway with the local suits, it was looking like going their way. One day he gets a call to the cell phone - wow, one of the big guns!
"We really like the work you're doing. Say, it looks like this deal isn't going to go our way - but if it does, we'll need a partner to help us interoperate with the existing infrastructure - you installed a lot of it, so you're first in line and we'd like to book you in advance just to make sure we can get you. What are your rates? Well, we'd like to make sure we have you for at least six months and we actually pay a set rate in this area of $$$
His argument is too tenacious, I can't remember any historical situation which would bear out this line of thinking. Come to think of it, weren't there some MS guys calling themselves "The Open Document Foundation"? This is too strange to be legitimate.
.doc history and allegations from Windows file Sharing programmers)
.doc to .odf already and while "better" handling of excel files is good and all, it doesn't mention why this isn't a problem with OpenOffice. I'd bet it's the same as one of the reasons people hate the old format, because Excel does something strange.
It's important to keep in mind the reasons we oppose the OpenXML format..
* It'll let Microsoft extend the blight of their ".doc" format for years to come.
* As with doc, hard to reverse engineer, if it becomes a standard and gets widely used, especially in government, we'll be stuck implementing it in OSS apps while they change it to be different (Bourne out with
* Binary blobs that could be anything, stuck into the code at Microsoft's request, obtainable only from Microsoft.
Lately there have been even better reasons.
* Allegations of corruption and mishandled votes.
In order to ensure the public good, we have to stand against that sort of thing. Being stuck reverse engineering a broken format is LESS of a problem than being in a situation where your votes get messed with. It wasn't a public vote I'll grant but it still matters. After the mess with the standard voting, they have to become an example to others.
While in the pro-camp, we have what?
* Better spreadsheet handling with Excel
* Legacy features of Microsoft formats
Handy sure, but it's not as if we can't transfer from
Basically, the benefits aren't as important as stopping vote rigging or the problems of being blighted with Microsoft lock-in and binary blobs.
How do you kill that which has no life?
1) This guy works for a company that sold its soul to Microsoft in exchange for a useless patent agreement 2) This guy got a large quantity of money from Microsoft in the recent past 3) This guy got a large quantity of crack from Microsoft in the recent past and consumed it 4) Going by the date in the letter (March 24) they released the letter 8 days early
Oh Miguel, you are such a kidder
Isn't he like a week early for April Fools?
Assuming this standard gets passed (God forbid!); and 6 months later we find it's business as usual with Microsoft hindering access to so-called standards, and not implementing the standards in their own products.... preventing interoperability etc. etc.
Can the ISO then meet again and de-recognise the DIS29500 standard?
If yes, what is the procedure for this process?
If you keep throwing chairs, one day you'll break windows....
"Superman, a prominent member of the Super Friends group has written a letter that strongly supports The Legion of Doom, arguing that if it fails, the forces of good will suffer. 'As head of the Super Friends, I want to promote truth, justice and the American way, none of which is accomplished by the anti-evil position' Superman wrote. 'The bottom line is that the Super Friends, among others, will lose if The Legion of Doom loses... Evil prevailing is going to benefit the Super Friends as much as anyone else.'"
First, literally, I don't see TFA. I see TFBE -- The Fine Blog Entry -- which quotes the letter, but doesn't link to it.
But I'll work with what I have:
Then OpenDocument is the correct, standard definition, and OpenXML will be even further from standardization.
The fact that Excel output varies by version and service pack, and is sometimes downright wrong, is all the more reason to ignore it. Approximate it, maybe, to make porting easier. Write a compatibility layer, even. But don't push through an entire second document spec, which is so deeply flawed in so many ways, just to make us match one particular iteration of Excel output.
Oh, and Excel output varies by version and service pack. WTF makes this tool think Microsoft will even try to adhere to a standard, even if it's their own?
It certainly would, wouldn't it?
Except for the fact that the OOXML spec doesn't include them. In all its six thousand fucking pages, not one mention of how, exactly, to implement LineSpacingLikeWord95. And what's he proposing -- delay OOXML until this can be included in the spec, and thus make it, what, twelve thousand pages? Or push it through in the faith (hah!) that Microsoft will add it to the next version of OOXML?
Consider, also, that there is a right way to do this: Styles. Extend the style system to support this quirky behavior. Support quirky behavior in an abstract way. Then, put the actual definition of LineSpacingLikeWord95 in the document itself, as a style. Translating back is easy, too -- just look for styles flagged that way, or just styles that happen to match the original format's quirk.
It would take some work, sure. But it would be pushing the work back to Microsoft and Office, not to ISO and any potential other implementations. And it would mean we don't have to carry this legacy crap with the format forever -- eventually, there will be no more Word95 documents, and no implementation will have to care that LineSpacingLikeWord95 corresponds to an actual way of saving a Word95 .doc -- just that it should look a particular way.
Don't thank God, thank a doctor!
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.)
It might even be true that OOXML as an ISO standard would be beneficial to ODF. However, there are the following problems:
* 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.
Wanna know how much Microsoft has reformed this sort of thing?
You can get it all here http://www.groklaw.net/article.php?story=20071023002351958"Where have all the good people gone?" - Jack Johnson
see comment 3.
So this argument is rubbish. I suspect they will not ever supply a proper mapping, otherwise it would just be used by ODF, and make OOXML even more redundant than it already is.
_
\\/ are accustomed' - First Lensman
I can see what he says - we will probably lose some advantages when OOXML fails; or rather, there are some things we won't get as easy access to. So the question is, I think: if we will be no worse off than now, will we have lost anything, really? I don't think we will have less opportunities than we already have, and the future seems to be going our way, as far as I can see. Microsoft are slowly, but sure, it seems, getting their come-uppance, and open source is going to benefit.
I have a hard time feeling much sympathy for Microsoft's predicament, really. They have been the big, bad bully for a long time, and in all that time they had no second thought about squashing anybody who remotely looked like competition; now they are beginning to feel the squeeze, thanks to FOSS, EU and countries who are beginning to realise that they could spend their money better on other things than feeding Microsoft. Maybe, once they have been cut down to size, if they seriously change their ways like IBM, maybe then we can begin to look at them in another light.
In some ways competition is good. I would not quite support OOXML, but maybe not actively despise it, if it was on a level playing field.
That is - if the votes were free and fair and based purely on technical merit I would have no problem with OOXML at all. In the spirit of free competition let the best format win to the benefit of all.
But the vote ARE NOT fair. Clearly and demonstrably so, see the past history on this subject. There is the stench of political and commercial interference in decisions that really do need to be taken on unbiased technical grounds. Mr. Durusou is clearly caught between a rock and hard place here - see the posts about the MS interference above - and something has to give, unfortunately that something appears to be his integrity and reputation* (*thats my narrow minded viewpoint based on TFA and others).
Bottom line, I don't think anybody will give this much thought apart from MS who will attempt to spin this six ways from sunday.
The alternative is that we all stick to .doc. You decide.
...with the semi-arguments put forward by my learned colleagues in the /. crowd, I still am at a loss to grasp the concept of the success or failure of one, proprietery file format directly affecting the success or failure(!?) of one which has not only been accepted as an ISO standard, but also one which is openly and fully documented and licenced for all to use for its intended purpose with little or no restriction?
Someone care to explain that to me in words of one syllable?
Operation Guillotine is in effect.
BSD licensed source code implementing the standard.
You can then take the source and modify it to fit in your system.
MS could do the same, but won't, and BSD gives no patent license anyway.
I don't know this fellow, but I do note one thing from Rob Weir's blog referenced upthread - that the sudden change of heart came about after a Mr. Durusau attended a conference in Seattle.
Now, Seattle and Redmond are fairly close, geographically speaking. I wonder if Mr. Durusau received some sort of persuasion from a company based in Redmond. I think we should be told.
If OOXML became an ISO standard the chances of ODF support in MS Office is zero. I'm sure Microsoft will act all conciliatory once they get their standard but they will never offer more than token support for ODF. If they produce anything at all I expect it will be some broken tools that conveniently convert ODF to OOXML but botch OOXML to ODF conversion.
How anyone can think that OOXML standardization is a good thing just boggles the mind. It will either kill ODF or marginalize it so much that it doesn't matter any more.
The alternative is that you sabotage the standard and they have absolutely no incentive of documenting anything, which seems far worse.
And it's a free world. If you don't want to use it, install OpenOffice and use ODF. Hell there are loads of standards I can't stand and will never use. But if I ever want to interoperate with them it's good that information, no matter how incomplete is published. I'd much rather have a few probably unused corner cases I can't support, like justifyLikeWordPerfect1980 rather than a completely undocumented format which is the current case with MS Office.
Seriously nagging them for ages about publishing a spec and then complaining that it's full of MS Officeisms just seems pointless politicking to me, especially as 90% of users won't even understand why that's bad. And actually no matter what happens with the standard, I suspect that most people will stick with whatever version of Office is site licensed to their company, regardless of whether the standard is ISO approved or not.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
It's mystery men all over!
What's the point of a superhero if there is no evil overlord?
One should point out that a significant majority of documentation out there is already final and should be non-editable.
PDF is already the defacto standard for this. So presently, OO can easily produce a PDF of a document which can be read by almost anyone. Any MS doc could be converted to PDF by proprietary software. So PDF is the common document format.
It's only when a document has to be edited by a number of collaborators, using different WP and OS that some kind of standard is required. Again, for the most part, the edited document is finalised and can be made into a PDF.
Now practically, typesetting machines can read a text document that is pre-tagged, so it understands font face, size, chapter number, paragraphs, quotes etc etc - and this is all done in plain text. No mystery here at all.
The battle between ODF and docx is the battle between MS and the rest of the world.
ODF should win, simply because it is monopolistic to force anyone to purchase software to view and edit what amounts to be public domain texts.
Don't be apathetic. Procrastinate!
When I lived in Malaysia last year (very nice, warm people with a really dodgy government), whenever a major project is stalled or changes direction, or when a prominant politican flips on a seemingly heartfelt poisition overnight (happens more regularly that you think) we all nod our heads and know that he probably got a new Porsche.
Why can't I shake the feeling that this guy has been bought off? Heck, Microsoft has shown it's willing to pay off Swedish votors for OOXML and a slew of other shady dealings.
Cheers, ~ Ruben
Either you've got trade secrets based on your file format, or you have an open standard. Not both.
Sure you can. It just costs extra to get it approved.
OOXML, the standard the best money can buy.
-
- - You can't take something off the Internet! That's like trying to take pee out of a swimming pool.
Is it incompetence or malice? Should we be laughing or waiting for a competitor to flush these turds into the Puget sound?
The funny thing is, I'm interested in what happens if MS loses.
I can see MS Going... "You know, it doesn't really matter if you make us an ISO standard or not, we are entrenched in 90% of your infrastructure. Good luck replacing that infrastructure. It will be over out dead bodies ODF is supported by MS-Office, and you are about to find some very unfriendly code in the next service pack that breaks Linux Dual Boot loaders, Breaks existing ODF Plugins, and adds a DRM Key to all documents opened."
A standard is open and implementable by everyone. This is impossible with Microsoft's current solution and we already have an ISO on documents that they could use. There's no need for another one just because Microsoft has not invented here syndrome.
Finally someone with some sense. Instead of being part of the torch wielding crazy mob against MS, he at least has thought ahead.
If OOXML doesn't get ISO, Ms is prolly still going to go ahead and use it in its products - which make up 90% of the office suite using crowd anyway. Does any of the normal users care about the ISO definition. They will continue to use Office products - Word, Excel, PowerPoint and share successfully with each other.
However, when some of us who use "other" products like OpenOffice etc. try to open these files, it wont be able to. and Ms won't be inclined nor interested in supporting or even divulging the details of its format anymore since it got rejected as an ISO std. So when you can't open an Office file, the people who send you the file are gonna say that _your_ office suite sucks - not theirs, since they will be able to open not just Office formats but ODF formats as well.
Sounds like a typical Colbert report spoof.
One thing about MS. They have an absolutely crappy product, and some of the worst tech support going (the fact that they have to pull this crap attest to their products strength; none), BUT, their legal is awesome, as is their marketing. If you look at the above, they are thinking in terms of not only controlling, but also marketing it. Notice the last line of "get the press". Awesome. I hate to say it, but I view this as one of OSS's weakness. We need to do a better job of advertising OSS. I thought that IBM was doing some nice ads around 2000, but they seem to have stopped them. Perhaps, it is time for OSS companies to think of setting up a joint marketing campaign that benefits all of them. Afterall, that would be no different than the code. It is joint development, with differential marketing. But a joint marketing campaign designed to push OSS, and then mentions the items could make a dent. Perhaps a set of ads designed to push OSS app server or just OSS OS' (show off Linux, BSD, and even darwin).
I prefer the "u" in honour as it seems to be missing these days.
From the thread on Groklaw
I reproduce here the response from grokker59 and below Ron Weir's response.
Authored by: grokker59 on Tuesday, March 25 2008 @ 08:27 AM EDT
Item 1: If DIS29500 is not approved, *national bodies* will loose a forum to work on DIS29500 - circular reasoning. If DIS29500 is not approved, NBs won't *NEED* a forum to work on DIS29500 !
Item 2: Microsoft-only vendors may lose contracts because Microsoft failed to get "their" format approved. Circular reasoning. By not standardizing on a proprietary, lock-in document format, those companies that only sell proprietary lock-in document software no longer have a guarantee of continuing sales to locked-in customers. They might need to support an additional product or two to continue getting contract awards.
Item 3: If OOXML is disapproved, then ODF loses because it has no ISO-based formula definitions to insure compatibility between ODF and the complete lack of formula documentation in OOXML ? How is this a comparison and why do I care whether ODF shares formulas with OpenXML ? Microsoft's Office 2007 does not use OpenXML. Neither are Excel formulas documented in OOXML to the extent that translation can take place. What's important is that ODF interoperate to the greatest extent possible with Office 2007 and future versions - not that it interoperate with a format that Microsoft has already abandoned and/or never implemented.
Item 4: OOXML/OpenXML does not define legacy features, nor does OOXML/OpenXML provide a mapping for legacy features. Furthermore, all legacy features were moved to 'deprecated' status in the BRM, so there is no requirement to support them in either OOXML or ODF. OpenOffice already supports MS legacy features better than MS products, so I fail to see the gain of supporting DIS29500 to provide something that ODF products (OpenOffice.org) already does better than MS products.
Item 5: "ODF has no ISO-based definition of the current MS format for mapping purposes." Since MS products do not implement DIS29500, this is is a non-issue. MS has already stated they do not feel bound to support future DIS29500 versions in future products, so ODF MSOffice mappings are never going to be ISO-based. Nor should we expect MS to open their file format protocols in future versions.
There is *certainly* no reason to expect that MS will "offer a seat at the table" to any public organization during the planning/implementation of their next version of MSOffice since they've already stated that they do not feel bound by DIS29500 or its successors in ISO.
Another view from the ODF TC
Authored by: rcweir on Tuesday, March 25 2008 @ 06:38 PM EDT
As Co-Chair of the ODF TC, let me say that Mr. Durusau's views in no way represent the position of OASIS or the ODF TC.
Of course, he is entitled to his personal views, and so am I.
Patrick makes 5 assertions in his latest 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
Youre right, we should use Malbodge instead of Brainfuck.
In all things microsoft, you should always ask one question: How much?
In this case, how much did he get paid? (and in what currency, it's not always cash.)
I mean, seriously, with every other company that would be paranoia, but MS has been caught with both hands in the cookie jar actually buying ISO votes. It is very, very likely that they are buying good press and "expert opinion" as well. With enough money, you can buy friendship. Not the real one, but good enough that few will notice the difference.
Assorted stuff I do sometimes: Lemuria.org
I'm sure I've posted about this previously, but I think it's important, so I'll post again.
Even though I didn't RTFA (and it seems to be disappointing from the comments I've seen), I'm going to agree in one respect. A documented version of an MS word processor file format is a good thing. There are lots of reasons for this and I'm not going to belabour the point by listing them all. But it would be good for everyone if such a thing could be documented and standardized.
But there's a problem and it's called the MS Word formatter. Doc files in and of themselves are not particularly difficult to understand (well, there are some strange bits, but nothing you can't wrap your head around eventually). However, how the Word formatter interprets these files on a case by case basis is extremely complicated and strange. This has nothing to do with "the evil empire" trying to screw people over. It has to do with a complicated, poorly written legacy application having survived 2 decades of rewrites.
You could easily write a specification to explain the file structure of word documents, but such a thing is useless without explaining exactly how everything is formatted in every situation. And that's a dog's breakfast. So MS is between a rock and a hard place if they want to do the right thing.
Either they abandon backwards compatibility with their formatter (i.e., old files will *not* be rendered exactly as they were previously) and write a good specification, or they keep their bizarre formatter and write a horrendously crappy spec. They obviously chose the latter, and I have a hard time criticizing them for that decision.
Does that mean it should be an ISO standard? No. Ideally they should deprecate their old formatter and rewrite it to do something sane (arguably the same could be said for virtually every word processor on the planet). But they are going to have to keep the old formatter to support old documents. And we are stuck without the ability to format those documents exactly, mainly because you just can't describe in any meaningful way how to do it.
Strangely, this would be good for their business because right now they have very limited penetration in the US legal community because their formatter can not format footnotes properly. Scrapping their old formatter in conjunction with a new file format would allow them to get this market. I have to admit that I don't quite understand their reluctance to do so.
As an aside, I don't particularly believe ODF is "the answer" to a file format since it also lacks some crucial information about how the formatter should operate in certain situations. However, it has the advantage of being a *lot* smaller and relatively easy to understand, even if it isn't totally complete from my perspective.
You can print out the document, scan it in as a new document and edit that.
...).
Changed.
The ONLY way you can stop it happening is by only allowing the one (or limited) physical copy to be present physically, signed and watermarked there and then.
Or by owning the machine the person you're giving the document to so you can prevent actions happening that you don't want.
There's no possible ability to prevent a document OF ANY TYPE to be modified and changed so that it looks original. Even in the physical world with holographic signatures (written in pen by hand by the person signing): we have had forgers for centuries. Millennia, even.
If you want to stop someone who ISN'T supposed to read it from reading it, you can encrypt the document and give the password to the one you want to read it (in whatever method you wish: OTCP, PGP,
The "need" for controlling what happens to a document you're giving to someone else is PRECISELY the problem the labels have with DRM: it cannot work. The only reason why MS are pushing it is because that protection mechanism can be patented and licensed to ensure that even if MS don't get the lock-in they desire, they can ensure they get paid for each and every program out there that uses documents.
At the moment 100% of the editable documents I receive are in MS Office binary formats. Which are completely undocumented. Gmail's viewer and Open Office can read sometimes read them fairly well, but still by no means perfectly. I still use MS Office to edit them or to view them if OO or Gmail can't. MS Office comes presinstalled on every single corporate machine I have ever seen, and I think the per machine license fee they pay is very low.
People won't start to use ODF just because it is an ISO standard. OOXML is more open than the binary formats, in the sense that a spec is published. It's also the default format of Office 2007 and later and will thus be widely used as all those companies upgrade. Regardless of how you feel about it, OOXML will gradually take over from the old MS Office binary formats as the format most documents are saved in at work.
There are two ways this can happen. One is that it stays totally undocumented and patent encumbered like the old Office binary format, which is still only fully supported by MS Office.
The other is that they publish a standard and get the ISO stamp of approval. That means they publish a specification and allow other people to re implement it without fear of a lawsuit.
I know which seems like the best option for me. Otherwise they'll close the standard, and sue anyone that implements patented features. The whole Government thing is bogus too. If they kept OOXML proprietary but convenient and provided inconvenient ODF support they can still end up with most people using OOXML. The small minority of people who need ODF will run their MS office documents through a converter just like they now do for PDF.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
As Co-Chair of the ODF TC, let me say that Mr. Durusau's views in no way represent the position of OASIS or the ODF TC.
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.
even if it's hard to see what justifyLikeWordPerfect1980 or whatever does. But so what?
Bullshit. Pure bullshit. Calling that "documented" is like claiming the eels in my hovercraft phrasebook from monty python's sketch must be a totally legit tourist's aid because all of the words are in English. Who cares if its wrong? Who cares if it makes no sense? Hey, the guy speaks English and that's all that matters. Just say "My ultimate weapon is the China cannon attached to my groin" whenever you're being searched at the airport, it's all good.
My final year project involved writing a bluetooth stack for a bluetooth v1.0 device. Sure I didn't have to follow the hardware guidlines but the bluetooth specification is over 1000 pages and I could grasp it (it took a very long time to read.) I also implemented the Compact Flash standard sucessfully within the same project, my only issue was trying to implement the FAT standard. I simply didn't have time to locate a detailed and good enough standards document (CF was just as hard to find btw.)
My project was able to discover other bluetooth devices, pair with them and recieve files which would then be stored on a cf card (getting the information off the cf card was the issue my process was quite extended.) It was done in assembly I designed my own cf and rs232 adapters (for the bluetooth device) to work with a custom 8051.
1 Designer/developer in less than 6 months dealing with something close to 2000 pages of component design documentation, system documentation and standards documentation. As long as the documentation is as well written as the bluetooth specification (which I don't think is great) I really don't see an issue with a spec's size, my biggest issue was using a 8bit controller to deal with bluetooth address which were several times larger than the total storage of the device.
Impossible hardly
It's about time this kind of dirt is made public.
you had me at #!
It doesn't matter what the editor of ODF thinks. Slashdot has already made up its mind. OpenXML has already been added to their simple binary belief system under "bad".
Thread summary:
Microsoft bad =>Microsoft OpenXML bad.
Open source good => Sun ODF good.
It doesn't matter if he points out that OpenXML as a standard will allow them to more easily standardize conversion between formats (since OpenXML not being an ISO standard will only dent its usage in the most official cases, likely prompting people to use the ODF plug-in for Office). Standardized formats in the mainstream benefit everyone. They underline the need for standards.
Read my post again. What makes you think I did "not know about it"??
That is what I was referring to! Most other readers seemed to understand that.
Acrobat reader 5 was somewhere around a 5.5 meg download. Acrobat reader 8 is 21 megs. It does the exact same things but is almost 4 times the size, how is that not bloated? I think the "super fast" load times you're seeing is from that new PC you bought, and not reader 8 being any faster or less bloated than reader 5, 6, or 7.
God is real unless declared integer.
Neither format is going to replace Microsoft's own de facto DOC format standard anytime in the foreseeable future.
As usual MrNaz is crushing. 90% of the world wants exactly this from their document formats:
I create a document, and anyone else I choose to give it to can get the gist of it with any computer they want. It does not contain macros, dynamically-link embedded Windows Genuine Front Pages(TM) or anything of that sort. It is a bunch of text separated into paragraphs, or it is a spreadsheet. Under "advanced functionality" you may file
-putting image(s) into the text document
-having 2+ tabs in the spreadsheet
The technology to accomplish this was boring in 1996.
My turnips listen for the soft cry of your love
"OpenDocument currently lacks formula definitions for spreadsheets,"
OpenFormula exists for years.
I think including Rob Weir's response is topical, but let's be honest here. He's pretty much the single most outspoken critic of OOXML. That he and Durusau are examining the same situation and drawing very different conclusions isn't much of a surprise.
Personally, I think Weir's kidding himself if he thinks Microsoft was on the wrong side of open standards, if wrong is defined as "bad for Microsoft." Office being Office, millions of people will still be using OOXML because the factors that most businesses evaluate in choosing a word processor / spreadsheet / etc. are far from the factors that seem to be important to Weir. It already will be the de facto standard regardless of how bad it is or isn't or what ISO or anyone else has to say, so it might as well be documented and open for others to implement without legal harassment from Microsoft.
Actually, legislation is forcing some government offices to publish documents in open standards. If Microsoft gets to pretend OOXML is an open standard, it's very likely I'll be required (by law, even) to deal with a document in that format.
Maybe you're not familiar with BF.
It's not a question of whether I, personally, like it. It's a question of whether it meets the requirements -- and of whether it serves any purpose, when there's already a perfectly legitimate standard out there (OpenDocument).
Show me where LineSpacingLikeWord95 is documented.
In what way is the actual semantics of LineSpacingLikeWord95 stored in the document?
Oh wait, it's not. Instead, the document just contains a tag called "LineSpacingLikeWord95", and you're expected to know what that means.
Yes, we've gotten that idea. Can they stop pretending it's a standard, though?
In other words, there's going to be some hidden property of a paragraph, that the user can't see in your app, because you don't know WTF it does. But there'll be a nice big surprise when it goes back to MS Office. That, or people will refuse to use your product, because it can't handle their legacy crap properly.
In other words, any competing product at least requires that people reverse-engineer MS Office. The whole point of publishing these specs are so people don't have to reverse-engineer them.
The alternative to what? Letting the standard through because it's Microsoft? Please tell me that's not what you're suggesting, because I thought standards bodies were supposed to consider the technical merits of a standard, not who wrote it.
Oh, and it might give them an incentive of maybe, y'know, supporting ODF, the real standard.
Except it's been pretty much fully documented, including old binary versions. Do you think they'll take all that back if it doesn't become a standard?
Let me make this as simple as I can: Publishing spec good, fucking up standards process bad.
Let them publish a spec, but it should not be a standard. If they want to clean it up to the point where it's complete, maybe -- and then there's still the problem where it's over ten times the size of the ODF spec now, and "cleaning it up" would likely grow it.
Your argument seems to be roughly equivalent to: "Yes, he turned in a truly pathetic homework assignment, but please give him an A -- otherwise, you'll just discourage him. He might never do homework again if you don't give him an A this time!"
Don't thank God, thank a doctor!
Ok... i tried to find out who this guy is. Open Document Format editor? I see no reference to him anywhere on the ODf pages. http://www.oasis-open.org/home/index.php. I see nothing on his website that has anything to do with ODF. All I see is MS fanboyism. This sounds a lot like that other "news" story that was going around where a "open Document format" closes up shop and says the ODF format is no good... and it had nothing to do with ODF just more FUD. Can anyone see how/why he is the Open Document Format editor?
The OOXML "war" in ISO is really a lot more important than OOXML itself (except for Microsoft, of course) and ODF.
It is about protecting a major standards body processes (bad as they are) and showing one of the major bad-behaviour corporation that they just can't buy their way everywhere.
If ODF goes to the trashbin in the process, it will be an acceptable loss. It is not like ODF is a good standard either, it is vastly superior to OOXML, but that's the same as saying a thief is vastly better for society than a serial rapist and killer.
Ask around. The Brazil delegation had written proof that ECMA screwed up royally when they accepted OOXML (even by ECMA's pathetic standards, which are *almost* down to "pay us enough"), but they were "worked around" and could not present it properly to everyone, and India refused to participate of the second half of the last meeting due to slights made against their delegation as well. You will find both teams had good reason to be extremely pissed.
OOXML can't be allowed to win, not after the stunts Microsoft and the corrupt people they bought have been doing. No matter the fallout. It is that simple.
Bullshit.
How would it not still be patent encumbered?
Well, except that it apparently isn't. The document you pointed to talks about Ecma standardization, not ISO standardization.
Also, I find it disgusting that you, like Microsoft, still seem to think that it's OK to just rubber-stamp something through as part of a means to an end.
Unless, y'know, they were required by law to use an open standard? Maybe an ISO standard? Maybe it would allow Ecma too, in which case, you've already got what you want.
Don't thank God, thank a doctor!
Excuse me (not), but dual "standards" for the same function clearly hurt. Because they're not identical, they clearly can't be completely inter-operable, and additionally require twice as much effort to implement, keep current, and decide which to use. So is that guy on crack?
"It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
You're just thinking "Wordprocessor".
....
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.
George W Bush, the leader of the White House has written a letter that strongly supports terrorism, arguing that if it fails, the coalition of the willing will fall apart. "As the leader of the free world I wish to promote peace, safety and freedom, none of which is accomplished by fighting terrorism", he wrote. "The bottom line is that if we capture Osama Bin-Laden national security loses... The constant threat of terror benefits our goals as much as anyone else."
Justice is the sheep getting arrested while an impartial judge declares the vote void.
Undocumented formats is just one of the major issues with OOXML. Here's the short list of things wrong with the OOXML and why it's bad:
MS uses their own DrawingML instead of SVG, their MS Math instead MathML, Dark blue is coded as 000080 and not 00008B (SVG and ISO), MS country codes instead of ISO country codes, etc. Some of them are documented; some are not. However none of them are approved standards themselves. This means that in order to use OOXML completely, software must use MS standards. This excludes any platform/software MS chooses to exclude including Linux, OS X, BSD, etc. For example the recommended format for DrawingML is WMF which is Windows only and there are no plans to port it to another format or platform. Besides being anti-competitive, the use of undocumented MS standards can be dangerous. For example, OOXML uses MS hashing and cryptographic functions which are not documented or approved or tested. Are these functions safe and effective? No one but MS knows.
OOXML uses units like English Metric Units (EMU) and "twips" (twentieths of a point). While defined, neither of them conform to any country's known units of measurements. Also in OOXML, different parts uses different units without any explanation. For example, some parts use twips while some parts are defined in points, half points, pixels, etc.
Many parts of the specification have undefined terms like the style "basicThinLine" (1 pt line?) and "plainText" (ASCII, UTF8?) . If you wanted to render a basicThinLine, you cannot.
XML should be human readable but OOXML is littered with abbreviated, unclear element names like scrgbClr, algn, blurRad, dir, dist, rotWithShape.
OOXML does not support RFC 3987 which means no Chinese characters in web addresses. Some functions are Western only: Networkdays() returns Saturday and Sunday as weekends which is true for the US but not Muslim countries.
autoSpaceLikeWord95, footnoteLayoutLikeWW8,mwSmallCaps, etc. Most of these are not documented. Even if they were, they require emulation of a MS product.
Well, there's spam egg sausage and spam, that's not got much spam in it.
He's early, it is still about a week to April Fools day.
Counter intuitive, indeed!
So, where does this idea come from if it seems illogical?
I'd say: Follow the Money.
Though I have zero reason to believe that the basis for the assertion that OOXML is good for ODF, Occam's Razor suggests there may have been some money from Microsoft involved here.
MS is alleged to have paid off members of national standards bodies to approve OOXML, it seems plausible to me that MS paid off an ODF supporter to be a shill for its position.
This is just my speculation, but it seems plausible to me.
n/t
I don't agree with Mr Durusau's position on OOXML approval, but the intimations that he went to Seattle to speak with Microsoft are pure mud-slinging. Patrick is very interested in ancient languages and documents, and in the use and development of new methods of analyzing and cross referencing such documents. Of course he would be interested in a conference designed around exploring the intersection of technology and ancient scripture.
GAH! I can't take it any more! You don't make a word plural by adding an apostrophe "s"! Unleash the dogs of war. Every man's destiny. CPAs make up their formulas! Is that so bloody hard?! I see otherwise intelligent, educated people making this mistake more and more often, and I'm terrified that it will become accepted. The other day, I caught myself doing it -- now I lie awake at night, afraid to sleep for I know that the "'s"es will return in my dreams.
So, uh, right. Sorry about that, had to get it off my chest. Carry on.
This is where you do not understand what affects a ISO standard has on the marketplace. When Governments start mandating ISO-document standards, every government supplier suddenly has to start supplying documents in ISO-document formats. ODF has already created waves in the marketplace because it is an ISO standard and its adoption by the public sectors is already happening. Microsoft fears that this could erode their market base in these areas and act as the thin-end-of-the-wedge in other related sectors. While its premature to write off .DOC now, give it five years of public sector mandates for ODF and the picture in new documents might look so very different. That is also why Microsoft absolutely has to use the fast track procedure in ISO to get OOXML through now - standard procedure for a normal spec in ISO might take 3-5 years and OOXML is a very large spec. Normal ISO procedures for OOXML might take a decade.
Cheers,
Toby Haynes
Anything I post is strictly my own thoughts and doesn't necessarily have anything to do with the opinions of IBM.
But if the person to whom you give the document wants to edit it, THEY WILL.
All that adding a security override will do is give a speed bump that may make it too much trouble. But then again, just ASKING them not to edit will work on 100% of respondents you can trust.
One of those missing formulas is the formula for calculating a Word95 date, which calculates the wrong date for certain dates as the leap year logic in Word95 (or was it 97) is incorrect. So in order to support OOXML you have to be able to create incorrect dates given any date. Yeah, that's what I want in a word processor. There are other stupid hacks like this, plus there are a number of formulas that need to be supported, but Microsoft hasn't specified in the standard how or what has to be done to support it, so there is no one in the world who can implement an OOXML compatible format EXCEPT Microsoft.
... what a useful standard, a standard only one company in the world can implement.
Hmmm
I thought it was 3000 pages...
Well that is still 2500 pages more than we need, at any rate.
"Microsoft irrevocably promises not to assert any Microsoft Necessary Claims against you for making, using, selling, offering for sale, importing or distributing any implementation to the extent it conforms to a Covered Specification" Unless, y'know, they were required by law to use an open standard? Maybe an ISO standard? Maybe it would allow Ecma too, in which case, you've already got what you want. The law only covers the file format you send to the outside world and you can export to it using a converter. I seriously doubt many goverments are going to ban people using
I hope you don't use USB mass storage devices, since that's another de facto standard that's a lot less documented than OOXML. Maybe the FSF should make an incompatible rival with less features and get governments to force people to use it?
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
When you've done all that to XHTML, you've now included MathML, SVG, PNG, ..
How do you store tracking information?
You don't store tracking info in the pages. Store your document in subversion if you want that, or use a diff-based file system. There's no good reason to abstract this to the level of document standard. It isn't a part of any other document standard, and it doesn't need to be a part of this one.
How do you store equations?
MathML
How do you store an index?
Anchor tags
How do you make links that will change?
Depending on what you mean, use EMCAScript, or use relative linking.
Line drawings?
SVG
I believe I did mention those things that would have to be added that aren't already part of HTML. With the exception of MathML, those things are *already* part of the existing standard.
ODF *is* what you'd get if you did what you asked for.
No, ODF is not written in XHTML. It does not encompass the page flow stuff built in to existing HTML parsers, nor the vast collection of code written to support them. It doesn't support CSS. It absolutely isn't the same thing at all.
It's what you get if you wanted to build what we're talking about off of Star Office instead of building it off of HTML.
Mod me down and I will become more powerful than you can possibly imagine!
Patrick Durusau is an idiot, because of one simple argument:
ODF is not difficult to implement. MS could implement it side-by-side with OOXML, and loose nothing. Implementation of ODF in Office 2007 would be sufficient to meet any government regulation. There's plenty of time to quickly finish the ODF plugin for 2007, and more than enough time to put ODF in Office 14.
Durusau got bribed or threatened, plain and simple. There's nothing to stop MS from implementing ODF as a checkbox, and all of this gamesmanship is an attempt by MS to keep ODF-only products out of government.
This simple argument answers all of his "reasons" as to why the broken OOXML standard should be fast-tracked.
WhiteWolf666 an exBush supporter. All you new-school,compassionate,save the children Republicans can rot in hell
5) OOXML does not define Microsoft document formats. It describes a framework, but there's thousands of details that can only be determined by reverse-engineering.
4) OOXML does not define legacy Microsoft documents without reverse engineering.
3) What does compatibility between ODF and OOXML buy us?
2) Good, that would give Microsoft an incentive to support ODF.
1) "If OOXML loses, then OOXML loses"? Recursive, no?
0) mind running over those again?
Any chance of getting this document in XPS format? Just asking...
Wanted: witty unique signature. Must be willing to relocate.
The nugget comparing OOXML to HD-DVD is compelling:
I'm not sure about MS adding Blu-Ray to XBox, but the point is that the document format war has much in common with the high-def disk format war. ODF, for all its faults, is already an international standard. It isn't too hard to support. Sure, it may lack a few important features, but that just makes it easier to support, and XML, as its X implies, is easy to extend. At this point, the question really isn't about whether OOXML also becomes a recognized open standard, but whether MS chooses to support the already-adopted ODF standard natively, or leaves ODF compatibility to third-party plugins.
In many ways, what happens with OOXML is becoming as irrelevant as what happens with HD-DVD. OOXML isn't chopped liver, but BetaMax was better than VHS, and TeX had more features than HTML in 1991. Sure, it would be really cool if both MS-Office and OpenOffice supported OOXML, like its cool that they both support RTF and SYLK, but that's ultimately a side issue. This pretense that anything other than ODF will be the lingua-franca is little more than a ruse. The standard is ODF, and the question is whether the 800-pound gorilla will play well with others, or continue growling and pounding its chest while others do its work.
Maybe. I spent five years working with Patrick on OASIS OpenOffice ODF and have the utmost respect for his honesty. His integrity is beyond reproach. His wisdom and expertise much appreciated by all who worked with him on ODF.
Having said that though, it's also true that Patrick is a long term guy who fully believes that we can harmonize ODF and OOXML through a one to one mapping. He believes that complete documentation fully describing both the syntax and semantics will enable this mapping.
He also thinks that the way to beat the undo influence and control of big vendors and the consortia they forge is to outlast them. Market facing vendors will always value their right to innovate over the interoperability of standards. They limit interoperability to protect their market driven innovation needs. Patrick recognizes this inherent tension and believes that you can't fight it, but you can outlast the forces that value innovation over interop.
I disagree. Patrick compromised on ODF interoperability many a time, the ODF metadata "XML ID" issue being the final straw for me. Allowing Sun's OpenOffice/StarOffice team to determine which ODF elements can have "metadata" and which cannot is a bit much. And i see no evidence whatsoever that ODF interop can somehow be fixed in the future. The ODF source code consortia of Sun, IBM, Novel and Google (all vested in some version of the OOo source code) are not going to change what is for them a good thing.
ODF does not have an interoperability framework and there is little hope that anyone will be able to fix the hapless compliance clause that enables unlimited use of undocumented extensions. In such situations, interoperability is only possible where specific applications come to agreement.
For those who might doubt these statements, consider that KOffice has been a participating member of the OASIS OpenOffice ODF TC for over five years, and they still can't exchange documents with OpenOffice.
MSOOXML is similarly lacking an interoperability framework that has some compliance teeth. That MSOffice 2003 Compatibility Pack OOXML differs from MSOffice 2007 OOXML should not come as a surprise. Ecma and OASIS are both vendor consortia groups, where innovation trumps interoperability by design.
ISO is bound to the business of "interoperability", and has very strict guidelines for interoperability requirements, that are themselves tied to international trade agreements and legal conventions. In this context, it is beyond surprising that ISO allows the "OASIS PAS" and "Ecma Fast Track" channels to remain open, with specification work remaining under the controlling influence of the vendors.
IMHO, the change in Patrick's position is entirely due to the realization that it is impossible to map between OOXML and ODF. I don't know this for sure, but when i read the German Standards Group (DIN) report on harmonization, authorized by the EU-IDABC and provided to ISO, i couldn't help but wonder how Patrick would react. The report definitively ends his OOXML ODF mapping dream.
Many wonder why mapping is impossible. I had more than a few discussions with Patrick on this. His point was that a schema is a schema. As long as the syntax and semantics are fully documented, no problemo. My point is that both ODF and OOXML are application specific; and, both are woefully lacking in "semantic" documentation. Add to this problem that both ODF and OOXML lack an interoperability framework with any semblance of compliance teeth, and the whole mapping issue becomes an impossible solution. Especially if interop is the goal.
The sad truth is that ODF began life as an XML encoding of the OpenOffice/StarOffice in-memory-binary-representation. OOXML is a bit more complicated in that it is a combined XML encoding of many MSOffice versions binary dump. The salient point however is that both are XML encodings of an application specific binary dump. From there the "theoretical" challenge is to fully document the structural syntax,
Here's the basic structure of just about any modern text markup language: you have large objects containing smaller objects, in a hierarchy. That hierarchy will be different for each format, but it will look something like this: "Chapters or sections contain paragraphs and lists and footnotes and sidebars and quotations. Lists contain entries, which contain paragraphs and lists and footnotes and sidebars and quotations. footnotes contain paragraphs and lists and... so on and so on... Paragraphs contain text. Text contains markup. Markup contains text." So you can have a paragraph containing text that contains an emphasised section that contains an underlined word, inside a list, and this paragraph can be moved to a footnote and the markup doesn't change, even though in a footnote running text is italic and emphasized text is roman.
Word documents don't have this. Instead they have "Paragraphs contain text, and following paragraphs. Text can have attributes." It's flat, not a hierarchy. The hierarchy is reconstructed by the program when it reads the file. If you do something that breaks the hierarchy, like putting a non-numbered paragraph in a numbered list, it fakes it by adding a new list paragraph after the non-numbered paragraph with a new list start. If you pull that paragraph out and put it in a footnote, you may or may not get your emphasized text fixed, the list may or may not get re-merged.
Generally when I want to produce documents that you can read in Word, I write it in HTML and give it a suffix of ".doc". That works.
I recently started using Pages. Lo and behold, Pages has the same broken document design as Word. It was excruciating trying to maintain the document... I ended up saving it as RTF, then using TextEdit to convert that to HTML, then spent a day and a half replacing all the markup it had generated... because if you had bold text containing italic text you didn't end up with [bold]Some text that contains one [italic]italic[/italic] word[/bold]. You didn't even get [span class=s12]Some text that contains one [span class=s13]italic[/span] word[/span]. You got [span class=s12]Some text that contains one [/span][span class=s13]italic[/span][span class=s12] word[/span]. No nesting at all. It didn't even produce nested lists, it had [div class=this] chunks of text for each indent level in each list.
It's SO much easier to edit the document in HTML than in these programs.
Does ODF do the same thing, like some modern descendent of NROFF (no, that's not fair, NROFF and TROFF had some hierarchy)? Or is it an actual structured document format?
Yes, they're fairly close--Redmond's a suburb of Seattle (and not one of the farther out one's really). It's only about 12 miles from downtown Seattle to the main Microsoft campus in Redmond and only takes about 20 minutes in light traffic (over an hour in heavy rush hour traffic though).
Personally, I don't really care if OOXML gets approved or not. It just shouldn't not be approved in its present form. Give MS a year or two to get the damn spec in order and I'll happily be out there as an advocate. It's just not ready now. Forcing it through will not accelerate the changes that are so desperately needed.
But the worst thing about bribery is that once you succumb to it, the bribers own you from then on. I mean they completely control you. Would you want it widely known that you took a bribe? Of course not; even a hint that you were corrupt would destroy you professionally. So you do whatever they ask from then on, however evil it may be. You are lost forever.
Maybe Durusau visited Bill Gates' house, and Bill made him an offer he can't refuse.
See previous post about corruption induced by a "telephone call from a VP". How much more influential could it be if Bill Gates himself invites you over for dinner, a few games of pool, and says you can walk away with as much cash as you can carry in two hands?
I can see the support already, Like there existing technology. You have a problem with a sql call limiting your expansion of a million dollar project you where incouraged to write with microsoft running everything.
You pay for the big time support. you get billed for it and the answer is that indefinatly eventualy they will have a patch. Yet you pay for this.. and in the end they have a new version and you have to start all over..
The People from the people or Microsoft (cause we know they are fair and are in it just because they want to help!)
Because a format designed to be blitted in the days of Windows 3.1 is a great candidate for interoperability and durability! Can I have some of what you're smoking?
How well does that hold up, legally? Especially the part about "Microsoft Necessary Claims".
Funny you should mention it -- see, open standards are about forcing people to be able to use whatever OS or editor they want.
And if you can export to it using a converter, then why not write an OOXML->ODF converter and be done with it? You don't exactly need a rubber-stamped OOXML for that to work. Hell, if Microsoft had done this right, there would be a "save as ODT" option in Word! Think of that!
Make what?
Free Software Foundation. USB is not software.
Oh, and there is a competing standard -- FireWire -- and there's the ad-hominim -- whether I use something is irrelevant to the discussion of whether it should be considered a standard. Once again -- If USB mass storage devices are truly a de-facto standard, and not a certified standard, then they are no better off than OOXML is, right now. Why do you feel the need to get it certified?
Don't thank God, thank a doctor!
And if you want something that allows you to convert a current MS Office document to it and convert back without loss of formatting, that something needs a way to store all the legacy attributes.
Yes you do need a way to store the legacy attribute. But that does not mean that is the *only* way that infomation is stored. Here is a sample of how to store "SpacingLikeWord95" in ODF:
<Style:Microsoft SpacingLikeWord95=true>
<ODF-command to make it act like SpacingLikeWord95>
Text, perhaps with more odf commands between the words, to duplicate SpacingLikeWord95 using only stuff in the standard.
<\ODF-command>
<\Style:Microsoft>
Note: I have no idea of the syntax but under the impression that ODF allows arbitrary data to be inserted in something called "styles".
A Microsoft product can back-convert this. It does it by recognizing the special attribute, and that causes it to strip out the special ODF commands that repliate the spacing and thus restore the text to it's original state. A non-Microsoft product can display this correctly by ignoring the Microsoft specific commands.
Actually, I quite like that. If you edit it and save for Word 97 then the changes in formatting will most likely be lost if they can't be expressed in Word 97 terms. But I think that's sort of OK.
.xls files in OpenOffice then the GMail previewer can't view them properly anymore. MS Office seems quite happy with them though. Since the people I send them to have MS Office, I pretty much need to use .xls. So it's third party code that gets confused by OO's xls files, not MS Office.
But it does show that any standard that allows people to save as Word 97 needs to have support for legacy attributes. ODF doesn't have this and OOXML does. Lots of corporate machines still have ancient versions of MS Office on them, so this is quite important. What annoys me about people blocking OOXML is that there's an element of compulsion about the whole thing. They think that making ODF the only ISO standard for documents they can then get governments to force people to use it. If Microsoft did this, they would quite rightly be annoyed. There's a double standard that I really don't like.
If they just wrote a good competing office suite and tried to sell it to people, that would be fine. In fact I use OpenOffice at home or on test machines which don't have MS Office and it's actually quite good. The only thing I've seen is actually sort of ironic. If I edit some
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
Actually, I quite like that. If you edit it and save for Word 97 then the changes in formatting will most likely be lost if they can't be expressed in Word 97 terms. But I think that's sort of OK.
Actually it would be preserved if the editor did not delete the token and the resulting text could still be reasonably back-converted. A program that thinks it's important to back-convert could recognize the token and refuse to make incompatable changes to the text unless the "SpacingLikeWord95" is removed first. In neither case are things worse than they are currently.
support for legacy attributes. ODF doesn't have this and OOXML does.
I was under the impression that ODF does have an official method, called "styles" for some unknown reason, by which an application can imbed extra information into the document that other applications know it is ok to ignore.
I have no idea if OOXML has that, but since the examples claim the keyword is "SpacingLikeWord95" or whatever, there does not appear to be any kind of common prefix or other method of deciding if a token can be ignored. But perhaps there is such data, and it could be used if my idea above is used.
In any case I think both should define a clear unambigous method of saying "this unknown attribute is applied to this block but it has no effect on how it should be rendered, so it is ok to ignore it". There may be questions about namespaces for the attribute, but prefixing it clearly with the product, such as "MicrosoftOffice:FooBlah" would work.
So it's third party code that gets confused by OO's xls files, not MS Office.
Well that's reverse-engineering for you. Open Office probably tested things by trying to get MS Office to open their output, and when it worked they could not do anything more. GMail probably tried to open MS Office output, and when that worked they were done. Open Office did not think to try to make GMail open their output, and GMail did not think to try to open Open Office's output. And you get exactly the result you see. This is why
The Word interface may be quite popular (I use Word 2000 at work and I'm not so impressed), but I think you are too optimistic about the time they might need to switch to ODF:
:-(
.doc import/export filter in Open Office (keeps most formatting intact, but drops the occasional detail). ;-)
From various critical reports about OOXML I got the impression that it is an attempt at avoiding to clean up internal chaos in Word. Tags that basically say "do stuff like Word 95" hint at a lot of accumulated spaghetti code for which no clear descriptions exist.
It could be malice in the sense of "let's make the OOXML standard unimplementable for non-insiders", but I consider it more likely that Microsoft themselves have no good descriptions of the finer differences between Word versions. Based on bad experience with my own "legacy" programs
This said, they could probably implement ODF support that mostly works pretty quick, or might already have it prepared. With "mostly works", I mean an equivalent to the
The interesting point is if the dropping of some details would affect things you enter in MS Word and find them changed after reloading the document from ODF. This is what currently makes working with Open Office in a Microsoft environment very painful:
The little differences that happen on the round trip
MS Office -> Open Office -> MS Office
will foul up your layout. This is currently somewhat embarrassing for proponents of Open Office, but if it happens in the round trip
MS Office -> ODF file -> MS Office
it would be a Vista-scale debacle for Microsoft. People would say that Microsoft Office "cannot read its own files"
C - the footgun of programming languages
I know Patrick fairly well. And having worked with him on the OASIS ODF TC for the first five years of development, i have the utmost respect for his integrity. He is also a renown and respected expert regarding the standards process and the specification contenders. His public support of OOXML, coming as it did just prior to the Geneva BRM, has to be sourced in something of extraordinary substance and concern.
:). If he really wanted too, Patrick is in a position to ram interop down the ODF vendor source code consortia throats.
He knows full well that ISO approval of OOXML is the end of ODF. It's that simple.
He also knows that ODF has serious interoperability problems. In May of 2006, an ISO directive was issued insisting that ODF be brought into compliance with existing ISO Interoperability Requirements. Yet nothing to date has been done. Like OOXML, ODF is seriously lacking an interoperability framework compliant with ISO Interop Requirements. ODF 1.2 should have been out in December of 2007, but continues to languish. The OpenOffice source code consortia of vendors driving ODF (IBM, Sun, Novell and Google) show no signs whatsoever of fixing the interop problems that allow them to claim compliance in spite of the continued and unlimited use of undocumented eXtensions and application settings.
This has to be very disappointing to Patrick. The larger problem he faces though is that he can't vote against OOXML after allowing - supporting ISO approval of an ODF specification that refuses to conform with ISO Interoperability Requirements. The interop compliance problems with ODF had to be fixed BEFORE OOXML came up for vote.
So he is caught between a rock and a hard place. The ODF source code vendor consortia refuses to fix ODF interop because that would impact their use of undocumented and often proprietary eXtensions. Although Microsoft is reluctant to publicly discuss this ODF issue, no doubt they are quick to point this out to Patrick.
Here's the thing. ODF can be fixed at ISO. OOXML can not.
It is entirely possible for Patrick to use his ISO JTC-1 editors position to craft an interoperability framework that would bring ODF into compliance with ISO Interop Requirements, which are themselves required by GATT and WTO International Trade Agreements (among others
OOXML on the other hand presents ISO with a very different situation. Because of the way the OOXML - Ecma charter is worded, i don't see how ISO JTC-1 could ever fix the OOXML interoperability problems. ISO approval of OOXML would include acceptance of a charter that defines and limits OOXML interoperability to whatever MSOffice determines it to be. If Patrick and the JTC-1 tried to bring OOXML into compliance with existing ISO Interoperability Requirements, they would have to somehow amend a charter duly approved.
Given that the JTC-1 has yet to address a two year old ISO directive regarding ODF interop compliance, what are the odds they will dare to amend an approved charter? Not good i think.
ISO approval of OOXML is a tragedy for all of us. For sure it's the end of ODF. It's perhaps the end of ISO as a respected standards organization. The issue of open standards itself will become a joke, with the reality of standards by corporation having us all wringing our hands in despair.
More importantly though, ISO approval of OOXML will break the Web. Microsoft will use OOXML to break from advancing W3C standards such as XHTML-2, CSS-3, SVG, XForms and RDF. These technologies are critical to the transition of complex documents to interactive web use. The MSOffice SDK beta demonstrates an easy to implement OOXML XAML converter. ISO approval of OOXML would establish MSOffice as a standards compliant "editor" for a proprietary MS Cloud of collaborative computing technologies driven by WPF specific XAML (fixed/flow), WPF, Silverlight, Winforms, XPS, and Smart Tags. All of which are proprietary replacements for W3C XHTML, CSS, SVG, XForms, CDF and RD