Slashdot Mirror
What Happens Next on the US Vote on OOXML
Andy Updegrove writes "As you may know, V1, the INCITS Technical Committee that had charge of the US vote on Microsoft's OOXML, failed to reach consensus on either approving or disapproving the specification. As expected, Microsoft has turned to the full INCITS Executive Board in an effort to salvage the situation. Between now and Labor Day, a complicated series of fall-back ballots and meetings has been scheduled to see whether the Executive Board can agree to approve or disapprove OOXML, in either case "with comments." A vote to approve would mean that addressing the comments would not be required for the US vote to stand, while a vote to disapprove would hold the possibility of US approval if the comments are satisfactorily addressed. The bottom line is that a vote to approve (either in the US or in many other nations around the world) does not appear likely, due to the sheer number of technical issues that have been raised with OOXML, and the expedited schedule upon which Microsoft has insisted throughout the process."
Interesting, although unsurprising, to see Apple following the money here.
Big difference. If it's the International Standards Organisation that's voting; it should not be subject to the machinations of the company that submits the standard under scrutiny.
According to the earlier article, V1 and INCITS were both extensions of the ISO evaluation process. Not just a US agency.
If you keep throwing chairs, one day you'll break windows....
Thought it might be Open Office XML but found out that it means
"Microsoft's Office Open XML (OOXML) formats"
Thought others might want to know.
Help end the use of Sigs. Tomorrow
OOXML doesn't open it.
It just describes it, and incompletely at that.
The sole purpose of OOXML is to torpedo any real standard document format. With Microsoft's machinations in the various ISO committees, it's ridiculous to continue pretending they have any intention of allowing real interoperability.
"I've got more toys than Teruhisa Kitahara."
I am against choice. I think everyone should agree with me and do as I do... and more importantly, stay out of my personal way as I'm the king of the world!
Okay, actually, keeping this particular "standard" as an option in "choice" is a potentially dangerous thing if for no other reason than the fact that Microsoft's "standards" are always moving targets. Invariably their specifications are subject to change or additional documentation. Their format is based on and/or defined by the behavior of specific other software applications or operating systems API code which is also subject to change.
To standardize on something that's not firmly documented is asking for future problems. Further, "standardizing" on something that references proprietary (not openly documented) software is just one step removed from standardizing the operating environment along with it.
And finally, to include OOXML as a required option would require all of the dependencies associated with the need to support the standard... those dependencies would be a MS Windows OS and a MS Office applications suite as I cannot imagine an effective or 100% compatible implementation by competing software when the specs are as nebulous as they are.
OOXML is still closed. When the spec has things like "This element means to parse it like Word97 with all of Word97's obscure bugs", that's not an open standard. What we're opposed to is having garbage like that officially recognized as an open standard.
Maybe you should read about the actual OOXML specification before saying that kinda thing.
a ilure.htmlc ally-.html4 /
http://www.robweir.com/blog/2007/07/formula-for-f
http://www.openmalaysiablog.com/2007/07/mathemati
http://www.noooxml.org/
http://ooxmlhoaxes.blogspot.com/
http://blog.janik.cz/archives/2007/07/18/T18_02_5
Read these. Then decide if you really, really believe that making this specification a standard will do anything good for the environment. The spec is simply too big and poorly-defined for anyone else to come close to implementing. If it was worth the paper it was printed on (and if you see the last link, that can be quite a lot) Microsoft wouldn't be trying to fast-track it--specifications should speak for themselves in terms of quality. Anything reasonable would have no trouble getting written into an ISO-accepted standard, no matter what company it came from.
Pop quiz: Why the hell is fast tracking with this kind of system possible? Emergency economic situations?
Wouldn't that be nice?
Unfortunately, the current OOXML (The Microsoft format) is so messy it's unmaintainable and unimplementable. Major holes, parts with undocumented binary data, etc. It's all a last-ditch attempt for Microsoft to continue it's office monopoly.
They are being way sneaky with the naming too. Note that the Open Office.org is called ODF (Open Document Format), while Microsoft sneakily called theirs OOXML (Office Open XML) - which confuses everyone, as many people think that OOXML is the "good" format, since they reasonably assume that OOXML means "Open Office XML". But it's not.
Our best attack right now is to make as many people as we can knowledgable of this name game.
ODF: Good and Open
OOXML: Bad and Closed by Microsoft. (It's not truly open when it comes to the details of the format)
Once it becomes an ECMA standard, the specification belongs to ECMA and will not be controlled by MS. MS has been saying this all along ("It's now ours anymore, it's ECMA's"). They DO want it standardized since they worked on it for years even before ODF and it's the format for their product.
There are two arguments here:
The first is that, independently of the existence of any other standards covering the same subject matter, OOXML is a poorly described, non-implementable, and otherwise bad proposed standard, and should be rejected.
The second is that that the existence of one standard covering a topic makes additional standards covering the topic less valuable, potentially redundant, and in some cases contradictory to the purpose of standardization, particularly when adopted by the same standards body.
Debate over the second seems to only make sense in a context where it is assumed or concluded that OOXML would be a desirable standard on its own in the first place.
There is nothing preventing MS from publishing their format. That is very different from being ratified as an ISO standard. I could publish my very own file format. But if I have shoddy documentation for the file format, it is useless. No one, besides myself, could effectively use the format.
Ratification is when a group (of people, states, etc) approve of something (a constitution, a file format). In the case of my file format, they wouldn't ratify my format because it is useless to them.
The impossibility here is not that ODF is incapable of rendering MS Office content properly; if MS wanted that to happen, it WOULD. (MS, after all, is in the best position of anyone to map their proprietary stuff to ODF and vice versa).
No, the problem here is NOT technical, it's ideological. The feature that Microsoft wants is user lock-in. The essential feature for MS is that THEY control the standard document format, and exclude all others from adequately rendering that format, keeping essentially all users as a captive market. This is more than adequately demonstrated by an objective examination of MS' public comments, their corporate conduct during this debate, and their private intentions as evidenced by the Halloween memos. For that matter, simply look at their corporate conduct over their whole history, and ask if it's ever changed for the better.
"My strength is as the strength of ten men, for I am wired to the eyeballs on espresso."
It's a minor point, sadly. There's nothing requiring Microsoft to follow any standard. They have built their software empire in part on avoiding all such things. The one thing that looks to be shaking the foundations of their dominance is the fact that most of the people I've talked to have looked at Office 2007 and do not like what they see.
The world's burning. Moped Jesus spotted on I50. Details at 11.
It's just formatting stuff that's actually considered deprecated and inappropriate for new documents. It's in the spec because if you come across them in converted Office documents you might want to either ignore them or tweak rendering a bit to make it at least not ugly.
If they weren't in the spec, it wouldn't be the complete OOXML spec used by by Office '07.
Save that the specs are ridiculously huge, and full of what really amount to undocumented references. It's not a useful specification.
The world's burning. Moped Jesus spotted on I50. Details at 11.
The specification is incomplete in that it references specifications that is not commonly available:
9 58261
http://slashdot.org/comments.pl?sid=254267&cid=19
Just saying it like it are.
We have two open standards. The Microsoft (a big company) open standard is setup to be backwards compatible with all the weird crap imposed by their prior formats (which makes sense, since documents tend to be stored in these formats), whereas as ODF is completely new format pushed by another massive software company... Sun (and sometimes IBM, another friendly open source lollipop factory).
What does this have to do with anything? Last I checked, OpenOffice can save in xml and Microsoft Word can save in ODF (with a plugin). This is like a cock-flexing match between the FSF and Microsoft and it's basically irrelevant to 99.99% of users and government employees.
If ODF, as it stands, were released by Microsoft and called Microsoft ODF, we'd have the same level of FSF, GNU, etc pushback.
Isn't mainstream software development about adaptation and matching and supporting standards- not massive legal battles for complete control?
Do you really want both Betamax and VHS? Do you really want both DVD and Laserdisk? Come on. Demand real open standards. It is not about free software. It is not about open software. It is not about non-commercial software. It is perfectly OK to have two or three proprietary closed software supporting ODF and one or two Open Source but not-free software and a couple of Open Source and free software all supporting one document standard with perfect portability across them.
Only when users demand the ability to switch from one software to another without any loss of functionality they will have the power in negotiation. In the present situation, they have to buy whatever MSFT charges. Did you really think people will be forking over 150$ for a spreadsheet and word processor 10 years ago? The whole MS Office was selling for 50$. Now it is supposed to be 500$. Dont you see where the customers lost the ability to negotiate better prices because of vendor lock in?
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
Well, no, I would say that's a simplification. OOXML is an attempt at vendor lock-in, whilst appearing to be friendly. Seriously, the point of a standard is to make it easy to implement and to make sure everyone follows it. But no one can implement all six thousand "AramaiacSmallCapsLikeWord6.2ForTheMacWhenRunningU nderSystem7.2.5" features, so only Microsoft gets to claim complete compatibility. Realistically, like PL/I was in the sixties, no one will implement it. However, it'll still be a "standard," and Microsoft will use that to force things down people's throats.
Also, if you are under the impression that this is equatable to some sort of religious or vi-vs-emacs holy war, you're quite mistaken. Look into these: http://en.wikipedia.org/wiki/Halloween_documents
See, Billy G. and Stevie B. really, genuinely are corrupt, horrible monopolist pigs who eat babies. Why do you think that antitrust suit exists?
These items should only occur in OOXML documents that were converted from predecessor Microsoft Office documents.
Which, for those who haven't extrapolated it yet, means "About 90% of them in any organisation which has decided to use OOXML as their standard file format".
5 years down the line and other suites are coming out with the "Supports OOXML" box ticked, but further investigation reveals that the organisation still has a huge number of files which haven't had much attention paid to them since the conversion process, are still relevant and don't open properly in anything other than MS Office, regardless of whether or not the product they're testing claims to support OOXML.
Reality: MS has been found guilty of antitrust violations and leveraging its OS monopoly to support and gain market its shares in other markets.
Check: The only software capable of even competing with the market leader product is being given away for free.
Conclusion: The "desktop computer office suite" market is not an open market.
Assorted stuff I do sometimes: Lemuria.org
You don't put something in a specification and not define how it works. It has no place in the specification. That's the whole point.
So here we have Microsoft working backwards. They take what they did and try to create a specification for it instead of creating a specification and then programming to it. Then they leave out parts of what is actually done in Office '07 so that other parties can never be compliant with the "specification". That would be akin to the TCP specification saying that bit 2 in byte 14 is a flag that says the checksum should be calculated like Windows 95 does it, without specifying how that is. This is just ridiculous. Do you not understand that some documents (probably all docs imported from Word 95 which I know is in the spec, I'm not sure about Word 97) WILL use this tag, and therefore anyone trying to comply with this specification will not be able to make the documents appear as they will in Office 2007? When importing a document from Word 95 or 97, Office 2007 should convert it completely to values defined in the specification, there should be no need for these tags for "backward compatibility".
If the specification has no way to make the spacing look the same, I would say that it is an incomplete specification (although it is 700+ pages). If there are certain quirks of Word 95 and Word 97 that would make the specification hard to understand, it doesn't matter. They should be defined exactly anyway so that ANYONE implementing the specification (and only the specification) will be able to produce documents that look the same.
It is not useful you can't calculate dates before 1900s due to backwards compatibility with other Microsoft products. How is that useful for other office products, as a standard and for users of the format.
Another suggestion (not mine; I've seen this elsewhere -- e.g. on Groklaw): MS-XML instead of OOXML. I believe in calling a spade a spade, and that's what OOXML is: Microsoft's own internal (proprietary) format, not an open standard.
licet differant, aequabitur
This is about whether or not to approve a standard. The people who do not want the standard approved have pointed out technical issues with it, severe enough that they should be fixed before the standard should even be considered for approval. But you get to ignore all those problems, because obviously anything any of the opponents say can never be based on facts. The whole bloody point of a standard is to make choice be among competing, but compatible vendors instead of among incompatible vendors. The problem, then, with OOXML is that it stacks the deck against anyone other than MS attempting to implement it, being essentially just an XMLised dump of MS Office's binary format with all the legacy cruft included. In fact, due to the legacy cruft, no-one besides MS can ever be fully compatible with the standard. All anyone else can do is claim compatibility with most of the standard, minus certain optional bits. And those optional bits will be rather crucial, since they lock up any documents converted from legacy formats to OOXML from being correctly interpreted by anyone other than MS. Contrast this with ODF, where any vendor has available to them the information they need to implement the entire standard and the legacy documents will be converted to generic ODF markup that can be correctly interpreted by any vendor that does implement the entire standard. And as for why I fear OOXML becoming an ISO standard is that it will then automatically become the dominant standard due to MS Office being the dominant product at the moment. No need for that pesky competition based on it's actual merits vs. ODF's merits.
See, Billy G. and Stevie B. really, genuinely are corrupt, horrible monopolist pigs who eat babies. Why do you think that antitrust suit exists?
Well, not exactly. Actually, Billy G. and Stevie B. simply have such a low opinion of their own ability to compete on a level playing field that they are desperate to find some way to game the system. And it's clear their problem is endemic-- a fundamental part of the way they've been operating the business for decades.
Is it possible to implement with relative ease into ODF, all the features that Microsoft sees lacking in ODF?
With the behaviour and errors that Microsot insists on including, no. It is possible to convert such gems as 1900 is a leap year in an application that reads/writes MSO file formats. To make that behaviour mandatory is absurd.
Most of the other complaints that Microsoft has are trivial/non-existent.
Furthermore, OOXML can not correctly render most of the world's writing systems, or languages.
Amber
Wind Beneath Thy Wings
Here's a possibility, one that might do the trick for the format name in question...
MS'OO'XML
Sure, it's a little longer, but it says who, in truth, the format belongs to, and the quotes around OO would indicate some falsity to the naming of the format, much in the same way that the CIA should have their middle initial surrounded by quotes as the sarcastic little bit of bullcrap that it is.
Thus far, that has had limited success, at least in North America. Microsoft has a lot of money, and there are a lot of politicians and bureaucrats who can sadly be bought in one way or another.
The world's burning. Moped Jesus spotted on I50. Details at 11.
http://www.mhall119.com
Microsoft is pushing the most important part of OOXML being it's ability to include old Office file data as opaque binary chunks (!). Problem is that their documentation of those binary chunks pretty much consists of 'try reverse-engineering old versions of office.' -- which is against the EULA for old versions of office.
Even if someone manages to figure out how to decode those old chunks properly, Microsoft's patent peace for them doesn't apply because they weren't explicitly described in the ECMA 'standard'. Many of these 'critical' parts of OOXML are also described in the documentation as 'optional', which means that their so-called partners (like Novel and linspire) who are creating readers can create converters that MS can trumpet as 'ecma compliant', but that don't handle the part of OOXML that they are selling to the MA (and other) government as the most usefull aspect of OOXML.
In other words, this 'standard' explicitly does not do what you see as it's most useful aspect.
You could easily end up with documents with critical parts readable only by Microsoft software .... and then find that Microsoft has stopped supporting those critical parts 'because they're optional'.
Sometimes boldness is in fashion. Sometimes only the brave will be bold.