You wouldn't know it from reading Microsoft's press release, but it appears that even they have realized that "open" xml has not made it through this round of ISO certification. the door is not completely closed on the matter yet, but this is a pretty big win for free and truly open file formats. Congrats to everyone who worked on this, and a big huge "you immoral asshats, this is why people dislike you" to Microsoft for rigging votes around the world. I hope the ISO learns from this set of events (though i'm not particularly holding my breath on that one).
With a global community made aware of the issues, contributing to the solutions and communicating broadly even the most competitive and powerful of companies are finding it difficult to tread on our freedom and get the world to buy into their lies.
To everyone who supported "open" xml in the free / open source community (unfortunately there were some, including some fairly well known people), I really urge you to seriously think about your position on this matter. the name "open xml" is a lie because it isn't open (there have been more than enough highly technical articles written debunking that issue thoroughly), it's a danger to true file format standardization efforts (e.g. ODF) and an unnecessary complication for office apps in general. We can win this one in the long haul and move everyone to ODF, but it takes patience and determination. It also means adopting the long term view rather than the short term myopia that support of "open" xml represents. Microsoft has gone this route (non-binary formats, standardization, etc) specifically because of pressure from the free software community. we are starting to win this competition and they know it. The question is whether they will capitulate and join us or whether they can subvert the processes and communities just enough to keep in their old, anti-competitive and unethical ways upon which the bulk of their business model is currently based. By changing the rules so others have to either change or, by their own choices, exit the game we can make this industry more rewarding, more ethical and a better citizen in our world.
To everyone who spent days, weeks and months of their lives exposing "open" xml for what it truly is: congratulations, thank you and you have my deepest respect and gratitude. People from around and even outside the community rallied to make this happen. I'm also proud of how the koffice developers got involved and joined arms with many others in the software and standardization world. You people rock =)
Subscribe to:
Post Comments (Atom)
12 comments:
It only failed fast track - MS will now push it through normal process. This should give them more than enough time to buy some more national standard bodies or to make some of their lackeys into voting members.
Well, the OOXML seems pretty open to me. And well documented too, at least compared to ODF.
What annoys me is that this should be technical decision, but somehow it has turned into a political one.
Sun and IBM (for obvious reasons) with most of the OOS crowd are lobbying against OOXML and MS is lobbying for it. I can understand why the companies are doing the lobbying, MS is doing it to give an open format status to MS Office and Sun is doing it to give it's own Office suite an advantage because it can't compete with the MS Office featurewise.
What I can't understand is why the OSS crowd is against OOXML ISO status? Let both formats have ISO status and let the competition bloom. In anycase these open XML formats will be good for interoperability of all these office suites and applications. At least I haven't seen any good (i.e. non-fanboy FUD)techical reasons against OOXML.
(And no, MS can't use ODF because it doesn't support all the features their office suite has and I believe Sun has opposed any MS proposed changes to it in the early ODF designing phase.)
@anonymous mark 1: indeed; but it's a great first step. step back a few years and there's no way Microsoft would've missed the fast track approval. things are changing, and we need to keep that change progressing.
@anonymous mark 2:
"Well, the OOXML seems pretty open to me."
really? who was involved in authoring it? (compare/contrast with ODF)
and does OOXML document existing practice or a standardized format? (existing practice and then rather incompletely, neither of which is what this kind of spec ought to be doing.)
"And well documented too, at least compared to ODF."
it is more complete, yes, as it documents existing practice and covers much (though not all) of Microsoft Office. ODF is not as well documented because it's a format standard in process, and that process is the proper way to come up with a file format.
that said, don't let the number of pages fool you. the documentation in the OOXML is lengthy but woefully incomplete and patchy.
"What annoys me is that this should be technical decision, "
it was. you obviously have not read any of the technical reviews of OOXML as they have extensively documented the *technical* issues with OOXMl. please educate yourself before commenting on this topic.
i think everyone would have LOVED a truly open, truly implementable, truly complete spec from Microsoft a that would've made it feasible for most people to actually implement interoperability layers with Microsoft Office. but Microsoft tried to game the system by offering something that isn't complete, open or implementable by third parties.
that is your technical issue, and that is why this is getting push back.
"but somehow it has turned into a political one."
thank Microsoft for that, don't blame the FOSS community. Microsoft brought this joke of a spec to ISO and they did so as a reaction to government regulations and and ODF making headway with ISO, OASIS and other standards groups.
Microsoft were also the ones who bribed and cheated the system, hijacking an international standards body for their own gain. this is unethical and immoral and completely, purely, 100% financially and politically motivated on their part.
"Let both formats have ISO status and let the competition bloom."
if both formats were worthy of ISO status, sure. they aren't. again, go educate yourself then come back here and we can talk.
"these open XML formats will be good for interoperability of all these office suites and applications."
broken record time: if "Open" XML was actually implementable, you bet. but it isn't. so .. *duh*!
"At least I haven't seen any good (i.e. non-fanboy FUD)techical reasons against OOXML."
google is an amazing tool. try it out sometime.
"MS can't use ODF because it doesn't support all the features their office suite"
here's the neat thing about open formats developed in a fair way: anyone with reasonable needs can have them met by engaging in the process of developing the format spec.
when koffice switched (still in process, really) to ODF there were things ODF couldn't support. did koffice devs use that as a reason to stay away and "standardize" their own format (which was already open and xml based)? no! they got involved (and remain so) with ODF.
see how it works? and yes, Microsoft could have and could still get involved.
they could hold on to their "open" xml format and work on ODF as a standard until it meets their needs. there is no need to try and push another document spec as an international standard, particularly one as fundamentally flawed as "open" xml. it is great that it is documented more than their previous binary formats, but taking it to the ISO and other standards bodies is wholey innapropriate.
"has and I believe Sun has opposed any MS proposed changes to it in the early ODF designing phase."
what were you saying about fanboy FUD? because this is pure bullshit. first off, Sun doesn't manage ODF. the OASIS group does they are open to industry involvement. KDE is involved with this group, for instance. we've managed to get modifications in to ODF. and you're suggesting Microsoft couldn't? and the culprit is the company they made a peace deal with a couple years ago? puh-lease.
it is fascinating, if disturbing, to see the level of disinformation floating around out there.
Where do you base this statement on that OOXML is not gonna make it...I was actually thinking microsoft was on a road to clear victory.
Fuck OOXML, long life to ODF!
anonymous #2:
> "At least I haven't seen any good
> (i.e. non-fanboy FUD)techical reasons
> against OOXML."
I urge you to reed this article:
* http://www.arstdesign.com/articles/OOXML-is-defective-by-design.html
It gives several practical examples on how defective the format really is.
"Where do you base this statement on that OOXML is not gonna make it..."
the fact that they lost the vote for a fast-tracked approval as a spec was a pretty good indicator that they weren't going to make it.
"I was actually thinking microsoft was on a road to clear victory."
not so clear anymore. they certainly could make it next year with the full process route. but they're going to have a LOT of items to address and a LOT of people to convince or simply buy off (which they did this time around as well, btw).
i thought it was a 99% sure thing they'd push the vote through, but then i watched the articles roll and the numerous groups (corporate, foundations, community organizations) pull together to spread the word and educate the necessary people.
and it worked.
so ... if they keep it up there's a chance microsoft will lose round 2 as well. i currently give them a 70-30 spin at making it. let's revisit those numbers in 6 months, though ;)
OK, am I the only one who has noticed that Aaron has started using capital letters? :)
@stripe4: Sweet candy-coated Lord — you’re right! I’d be willing to bet he was testing to see if anyone would notice, or if we’d all be too busy celebrating the news! :P
I suggest anyone who isn’t already aware of the fatal flaws in OOXML take a look at the article previously linked by anonymous #5, and also NoOOXML (read the links under the “Issues” section on the left).
So, you’re done reading all that? Great. I’m sure you now understand why the complaints against OOXML are far from “fanboy FUD”.
"I suggest anyone who isn’t already aware of the fatal flaws in OOXML take a look at the article previously linked by anonymous #5"
Well that was exactly the kind of lame FUD I was talking about. No substance whatsoever.
Miguel responds quite nicely to this in this Slashdot article:
Miguel on Slashdot
Please, quit quoting the fools.
Well that was exactly the kind of lame FUD I was talking about. No substance whatsoever.
Miguel responds quite nicely to this in this Slashdot article:
Miguel's post seems to get bandied around be a great many people ;-).
I'm afraid Miguel needs to seriously get a hold of himself, because he hasn't the faintest idea what he's talking about. He's going defensive and talking strictly about OOXML, which is merely an abstraction, and Stephan Rodriguez is talking about the only practical implementation of OOXML we have - Office 2007.
It's the only test container there is for OOXML, and that's the point. You can argue about the rules in ECMA-376 all you like, but without a practical implementation it is meaningless.
There are rules for modifying the schema and Mr Stephane is not happy with that. Had he followed the actual rules he would have had no issue.
Can Miguel inform us of what these rules are, because all Stephane did was to add a cell element with a value consistent with the format of everything else in there? There's no rocket science here, and with no example, the is meaningless.
VML is labeled as "deprecated" in the OOXML documentation (Section 8.6.2, page 25) and it states
Another nugget people come out with. I really don't know what a deprecated technology is doing in a new format, but it's just a pity that older MS Office documents (billions of them) converted to docx will contain VML. No application but MS Office will be able to do anything with it.
Given that Microsoft's stated goal of OOXML was backwards compatibility, I just wonder what the point of this is.
It is a valid criticism of the binary file format used by Excel: the new version has not been documented; But that has nothing to do with OOXML. This is just padding.
Hmmmmm. Obviously he didn't read the article and hasn't been sent documents like this:
http://www.codeproject.com/cs/library/office2007bin.asp
An awful lot of what Miguel says is flawed, because he comes up with a lot of arguments that people like Rick Jelliffe come up with. Take the actual versus stored numbers:
The precision issue that he brings up, I suspect is merely an issue with double format precision. He claims that the data is unusable and there is a loss of precision, but handing that out to a C compiler will produce the expected result with no loss of precision.
OK Miguel. Why is this acceptable in a XML, human readable format, and where in the format specification does it tell me what execution environment I need to run it through?
Rick Jelliffe used the same argument for bitmasks in OOXML. Well, yes I can read them with a XML parser, but discerning any meaning from them is an entirely different matter. I need to shove that parsed XML element through another execution cycle.
XML has to be taken as-is, and any special formatting needs to be documented. You can argue "Oh, if you shove this through a compiler you'll get the right number" or "This is a problem with double precision......" all you like but it's not defined:
https://www.blogger.com/comment.g?blogID=283390674923940532&postID=7772935878076524105
I would no problems if ECMA 376 would tag the values in a way that defines the bias, and therefore allows proper round-tripping of data regardless of the environment.
Is it what there is in ECMA 376? No, there is not such thing, Microsoft did not (or could not) make anything specific other than a small remark where they say "numbers should be as accurate as possible". It's a little vague don't you think?
I did think about offering a rebuttal to Miguel, but there's no point because it's just a daft post from someone who should be clever enough to know better. However, sadly, cloning Microsoft technology seems to be his only aim in life.
"Please, quit quoting the fools"
indeed, i wish people would quit quoting Miguel on this ;) normally i'd be a wee bit more polite, but Miguel's post was full of such invective.
Miguel discounts many of the issues as "well, that's an issue with excel. in particular, Miguel doesn't seem to grok the fact that if the spec for OOXML doesn't define the file formats it's supposedly covering, e.g. Excel files, then it's pretty useless isn't it?
but the typical Miguel part of that reply is on number formats where he really does mischaracterize the position of the paper. he says that the number formats are described in the spec contrary to the paper's assertions. well, if you read the paper, you'll find that the author does interpret number formats there ("The second one is particularly interesting, it says : use the French locale (40C), if the number is greater than 120, apply red, and do formatting as follow, with plenty of padding/layout special characters")
but then the author goes on to note that not all sequences are properly documented, some are described (as Miguel notes) but not specified but most importantly .. and here's the part Miguel brilliantly side steps in his attempt to scuttle the article .. this isn't proper XML or the sort of thing one expects to see in such a standardization spec. that was the meat of that point, really.
now, let's also not hyperventilate over this one article either and forget the hundreds of other items noted that have nothing to do with excel. the excel article was simply the latest one to get attention, but there are volumes of information that predate it that cover the Word format in particular. borders, anyone?
so yeah, Miguel appears to be playing the apologist in this one. which is too bad. i can empathize with and understand the pragmatic stance: with better documentation we can better implement filters. but that's a completely different issue than making something into an international standard or heralding something as Generally Good, which is where i feel Miguel goes off the track.
Post a Comment