OOXML Denied INCITS V1 Approval
Xenographic writes "INCITS V1, the US group responsible for the US vote over whether or not ANSI will grant fast-track approval to Microsoft's OOXML format, failed to reach the 2/3 consensus required to recommend OOXML to ANSI. What makes this vote interesting is the graph in the article, showing all the new Microsoft business partners who joined INCITS just this year to vote for OOXML. The INCITS Executive Board will now deliberate further, until they can come to some agreement on what to recommend to ANSI, but it's pretty clear that Microsoft is pushing OOXML as hard as it can."
Guys,
We'd all love to see the proprietary and over-complex OOXML file format die on the vine. It's sickening how they've purposefully obfuscated the issue, how they've picked a name that's confusingly similar (think Florida's 2000 election all over again!) and have lied and misrepresented what it is.
But just look at that graph! The lengths that Microsoft will go to in order to prevent people from being free of the vendor lock-in... Cash is king, and Microsoft has more available cash than many countries's GNP. How far can they corrupt the process? Probably far enough, with enough time and money, and the only holdback is the time.
What we need to do is simple: continue building world-class software. Continue to push for open standards. Make quality, useful, non-locked software and eventually, the marketplace will correct itself. That we've come this far is a testament to the power of the marketplace.
I have no problem with your religion until you decide it's reason to deprive others of the truth.
but It seems that the OOXML format is intentionally large/bloated and hard to implement. I get the feeling that MS wants people to implement the "standard" to the best of their ability while changing things ever so slightly in the MS office implementation-- like what they did with the Microsoft Java VM. This way the majority of people (most of which already use MS office) will be hesitant to ever switch to a competing product.
... which is war by another name.
They're supposed to be setting up mechanisms for cooperation. But all too often they become political battlegrounds, where each member organization tries to warp the standard to make things easier for itself and to sabotage its competition.
Now we have Microsoft going a step further, not just trying to get its own stuff approved as a standard, but packing the committee just before the vote.
And missing by one vote. Oops! B-)
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
If Microsoft is able to buy ISO's approval of this farce, it would destroy ISO's credibility. Does ISO want to commit suicide?
And yet, Microsoft might be cutting its own throat. If ISO loses
its integrity, there won't be any more standards, and Microsoft won't be able to claim it has a standard.
Consider, if you will, the need for metaphysical symmetry. /. karma analogy?
Ponder the roughly decade-long pageant of XML "textnologies" that were supposed to magically unfrobnicate everything, and usher in Web X.O.
From a certain aesthetic/spiritual vantage, we need another decade of unrelenting rejection of bloated obfuscations just to bring the software industry back to a contemplative, resting state.
Or has this just been dogma lifting the leg on another bad
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
Yeah, that's definitely the best way to do things - giving Microsoft another box of ammo in the proverbial war. "Oh no, all these zealots joined the organization JUST TO HURT US. We're VICTIMS! It's unfounded! Don't support these lunatics!"
There are also some other issues to consider. What other responsibilities does this organization have? How will they be fulfilled them when the only reason people joined was to stick it to The Man? Or is everybody just going to quit cold turkey and give Microsoft reason to call for a recount/vote/whatever?
How about when the document tries to patent mathematical formulae and then put it under "reaasonable and non-discriminatory" licenses that conflict with the GPL (yes I know they backed down to BSD compliance but how hard did we have to fight!)?
How about when they use binary formats within the XML for "backwards compatibility"?
How about when they have deliberate bugs in the standard so that "converters" don't work?
How about when they don't include ODF by standard in the possible file formats to save in?
If you want to complain, the guy directly responsible is a Micro$hill scumbag called Brian Jones who pontificates at great length on his blog about supposedly technical aspects but strangely doesn't mention the politicians they've bought and the committees they've conveniently stuffed full of cronies and shills and the honest men and women (like the IT manager in Massachussetts) who have lost their livelihoods and have suffered such great stress because of him.
Why don't we let him know what we think of his morals here?
"Oh no, all these zealots joined the organization JUST TO HURT US. We're VICTIMS! It's unfounded! Don't support these lunatics!"
Um, that's exactly their tactic.
"Son, never start a fight, but always finish one."
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Of course, it isn't over yet. I get the feeling that msft will win. Hard to lose with all that money, and influence.
Yeah, it is their tactic. And if we adopt it, they will be the ones to finish the fight.
Ummm, if we don't adopt it, they win. US votes for OOXML to be an ANSI standard. Fight over.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
It's merely the result of some poor sod documenting the Office formats, which are essentially dumps of the programs' internal state. What you see is merely the consequence of the fact that Office is held together with spit, bailing wire, and the curséd blood of sacrificed Microsoft H1-b programmers.
No, it's ugly because M$ has been playing this game forever. Office 2007 does not export to systems before Office 2007 is because it can't and it won't export well to any other system but it's own. M$ is going to play this game as long as people fall for it. Corrupting standards bodies is part of making people believe that this time they've changed. If they wanted to do something good for their customers they would be using ODF, which is a complete, reasonable and free standard.
Friends don't help friends install M$ junk.
Exactly. It looks like they gave it this name specifically to confuse people. I think OpenOffice should sue them for trademark infringement. I'm pretty sure MS would sue me if I released a product called PointShare portal server.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
It should be pretty obvious. Microsoft is afraid of losing lock-in.
.doc format today it is likely that 95% of the ODF documents would never be read or written by anything other than Microsoft word. And Microsoft would (initially) make exactly the same amount of money as they do now. They may even make a big windfall, if the ODF read/write is only a feature of the new version that people need to buy.
Yes it is quite certain that if ODF was required, Microsoft word would read/write ODF. And Microsoft word would almost certainly still be the number 1 word processor, and just like
The difference is that a number-2 word processor could then at least exist.
Microsoft is not worried about Open Office, that is just another bit of FUD they throw out (they act like there is some physical impossibility of any program other than an open-source Open Office working with ODF, which is a blatently false, but unstated, premise, of all their arguments).
What they are worried about is a *commercial* number-2 word processor. Say Google-word. Or maybe a company we never heard of. But suddenly no "something is wrong with open source" arguments will work (whether these are FUD or not), and any other argument against it will sound like Microsoft is claiming that they are the only company legally allowed to write software.
Such software would cut far more into Word sales than Open Office (I think the result would be 50% Word, 40% this competitor, and 10% divided amoung Open Office, a dozen other free open-source products, and 5 or 6 other commercial attempts). Retaining their market share would also require them to compete on functionality by developing the software, further cutting profits.
More serious is that it removes a possible lock-in for server products for the office. Even if a place uses 100% Word, the pointy-haired boss may actually have a hint and question why the "microsoft document server" they are thinking of buying will not work with this possible competitor, and for the same price they can buy the IBM unit that works with both. Microsoft will be forced to make such products that work with both or they will lose all the sales. But they will then lose that lock in, and then lose the lock in of things that run on or talk to these servers, etc, etc.
Why do legacy documents need to be prserved explicitely within the format?
Is the format somehow inadequate that it has no other method of specifying word 95 compatible formatting?
As an example, one of the issues i read about was that some old version of word would use a font 2 points smaller when "small caps" was turned on, surely the conversion process could simply reduce the font size within the output file, rather than having to use an explicit backwards compatibility kludge?
There's no sense in polluting a new format with crap like that. Compatibility with older formats belongs in the converter, not the format spec.
You've also forgotten the formula issues disclosed recently, where the spec doesn't fully document how formulae should be handled.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
As an example, one of the issues i read about was that some old version of word would use a font 2 points smaller when "small caps" was turned on, surely the conversion process could simply reduce the font size within the output file, rather than having to use an explicit backwards compatibility kludge?
You're talking about a semantic issue. Your argument is basically the same as saying "Why do we need a bold tag in HTML, why can't we just specify a style that uses a heavier weight?" There are cases where there are semantic differences between small caps and merely using a smaller font style. Word processing documents are not just words with formatting (though many people treat them that way), they have tables of contents, links, indexes, styles, etc... semantic markup.
The whole point is to preserve the original semantic information, not do nasty (and lossy) conversions that destroy the original semantic content, which always has to make assumptions as to the meaning of those semantics. That's a process that will always be error prone, and in certain fields (legal, medical, etc..) that's simply not acceptable.
Let's take an example. Suppose you have 10,000 legal documents written in Word 95, and many of them use "small caps" to indicate a specific legal meaning. Now, let's convert the documents to ODF, and those "small caps" are merely converted to a smaller font. Ok, it may look the same, but what if I want to search through my document management systems for all documents that have terms with the specific meaning that small caps were meant to represent? If the documents are converted with that semantic information intact, I need only return all documents with 'small caps'. How do you do that with the converted document? You can't really.
That's the danger of conversion. Not all data is in the data.
If you need web hosting, you could do worse than here
Again, I call BS - my experience of dealing with legal firms in the 90's was that they all (without exception) used WordPerfect, so the idea of a corpus of 10,000 legal documents in Word 95 format is numinous to say the least.
Perhaps you could expand on what specific legal meaning would be represented by 'small caps' in Word 95?
Besides, one of the drivers for SGML was to allow semantics to be stored as part of a document, and ODF, as a proper subset of SGML, is extensible in this way, in a manner that OOXML with its references to proprietary formats is not.
Your argument is simply fallacious - if there is a specific semantic meaning to 'small caps', the proper route to conversion is to create a well defined semantic tag for that case, and as an attribute to that tag, specify a smaller font - not to simply preserve an intrinsically meaningless attribute like 'small caps'.
One swallow does not a fellatrix make
Is there a semantic standard for using underline and strikethrough, or is it some arbitrary convention adopted by someone at some time?
There is a proper standard for semantic markup, and it's called SGML.
The proper process for conversion of an arbitrary markup scheme would involve the creation of a translation schema, and the use of a proper standard (hint - not OOXML) for the output documents.
OK - you work in document management, so you have to deal with real-world situations in which people use arbitrary conventions and proprietary formats, but that's no reason to defend OOXML. Microsoft having a dominant position in the marketplace does not excuse them from a duty to do things properly - they should adopt ODF and (as another poster points out) use namespaces to isolate their idiosyncracies.
Sorry for the 'Microtroll', by the way - I'm always a little intemperate in the mornings :P.
One swallow does not a fellatrix make
Wouldn't we just complain about them "embracing and extending" ODF? Anyone remember J++. They tried to make their own version of Java that compiled against the JVM and Sun sued them. So instead they went and built .NET and C#. Now we have C# and Java to choose from. In a way the competition has been good. In a way it kinda sucks.
I can almost guarantee that if MS said "we're gonna support ODF" we'd be predicting how they're going to embrace and extend it.
because I have been enjoined by this Holy Office to abandon the false opinion which maintains that the Sun is the centre
Not true. Read my comment here. The idea is to extend the style engine to be able to support most of the arbitrary crap, so that actual "SpacingLikeWord95" can be implemented as a style in that particular document, and need not be retained for posterity in every single implementation of ODF (or OOXML) -- but implementations that don't truly understand SpacingLikeWord95 will still be able to present the document properly, or search/index it based on arbitrary properties like that.
You know, in most standards, deprecated stuff is deprecated specifically because it is going to be taken out, so the "depricated" notice is to tell you to stop using them before they are removed permanently.
If that's really what Microsoft is doing, then they are basically doing exactly what I suggested (take them out), just more slowly.
Then why are they in the fucking standard (and in Word 2007) if they're not supposed to be implemented?
Ok, so not only are they not meant to be implemented in an office suite, they're not even supposed to ever show up in a document. So take them out of the standard. No need to have a six thousand page standard filled with crap like that.
Which is exactly why these legacy tags are a mistake, if they were ever intended for anything other than lock-in.
Since, as you say, it's suggested that you NOT implement them, that means old documents, even in the new standard, will only be readable as long as some version of Microsoft Office is still around. So, if MS Office is ever dead and buried, these documents die with them.
Which kills the whole point of having a new standard in the first place, according to you. (Another good reason for standards is to allow interchange between competing products, but that's obviously not Microsoft's intent here.)
They do. It's called namespaces.
They are not included in the standard, of course, for obvious reasons. But they are there, even if I think the problem would be better solved with styles.
You know, I'm not convinced you're trolling, but I'm also not convinced that OOXML serves any useful purpose. The only reason we're even having this conversation is that Office supports OOXML and not ODF. Were it not for that, OOXML wouldn't be given a second thought.
Don't thank God, thank a doctor!