Posted
by
ScuttleMonkeyon Monday March 12, 2007 @05:53PM
from the just-keep-pushing dept.

Lars Skovlund writes "Groklaw reports that the Microsoft Office XML standard is being put on the fast track in ISO despite the detailed complaints from national standards bodies. The move seems to be the decision of one person, Lisa Rachjel, secretariat of the ISO Joint Technical Committee, according to a comment made by her."

There are all sorts of ISO standards that people refuse to use in their current form. Not seeing this one as that big of a deal however. I'd rather have a published standard for microsoft interoperation via XML file formats then the old.doc &.xsl files.

Like, say, the C99 standard.. it's 2007 and we still don't have a conforming implementation. The committee failed to perform its mandate, codifying existing practice, and we, the developers who use this language, have suffered as a result.

There are all sorts of ISO standards that people refuse to use in their current form.

The article linked to that M$ party line statement [channelregister.co.uk], and it's pathetic on two levels. The first is that it's a sorry excuse to push a new bad standard. The second is that it's admission that Microsoft Office XML is a bad standard.

The parade of backlash to their bullying is heartening. The tactics are, as usual, backfiring on them. "Microsoft, just say no." sounds like a nice slogan.

Why does it matter if OOXML is an ISO standard or not? Microsoft is already using it in Office 2007 and people are creating OOXML files. MS just wants it to be a standard to lend the format an air of officialdom and to dazzle clueless managers.

It also serves to keep themselves under consideration as various government bodies move to use only openly documented standard data formats to ensure that the data is accessible in the future. Without the perception that they can deliver on that need, they will no longer be players with regard to government data which, as we know, has a bleeding effect against other entities such as businesses that do business with the governmental entities.

The point is that there is no standard. It is not clearly defined. Microsoft wishes to certify an incomplete standard...They are not publishing it. They just want certification on incomplete documents.

So it's time to stop being irreversably intermeshed with the microsoft file formats or start complaining to Microsoft to change their ways by fully disclosing the formats specs.

I just don't see what people don't get. The problem here is Microsoft and Microsoft has no interest in fixing it.

Correction, Microsoft ALREADY added ODF support. Go download the addon off Sourceforge (http://odf-converter.sourceforge.net/). Microsoft provides technical and architectural guidance, and pays for that project. I'm all for bashing MS where it's due, but try not to bash them on topics where you're wrong.

Is it built in to the latest version of office? If not it's all fluff. I can't publish an odf document to an internal mailing list and tell 80 co-workers to "just download this plugin to open it", that's silly. Granted people seem more than willing to download plugins, codecs, archivers, etc just to get to some content that shouldn't be using it.. but that really shouldn't be encouraged, it's horrible for security and an annoyance on users.

Why not include it by default then? There really isn't anything stopping them, they simply do it to appease the technologically-minded users who will actually look for an ODF plugin before complaining. At least providing native ODF support from the off would be a step in the right direction, even if it wasn't the default filetype to save as.

The "M$ wag" where you posted your brilliant "bubba" flamebait [msdn.com]? Which the guy actually took the time to answer in good faith? Is that it? Feels good insulting people on the internets, doesn't it? Calling them names behind their backs? For someone who complains so much about how "insulting" people who don't agree with you are, you sure know how to "dish it out" like a big tough dude. Way to go.

"There are all sorts of ISO standards that people refuse to use in their current form."

But how many of them are used by a product that has a monopoly share of the market? People will buy Microsoft Office 2007. People will save almost all documents using the default OXML format. People will feel the pain of Microsoft's lock-in once more.

I'd rather have a published standard for microsoft interoperation via XML file formats then the old.doc &.xsl files.

This too seems to be the M$ party line - the magic of XML is better than their old secret formats. It's bogus, of course, because their new XML is as poorly defined as any of their formats [slashdot.org]. If M$ was interested in interoperability, they would use ODF and make a converter using their knowledge of their crusty old standards. It's an impossible task because their old "standards" were contradictory to begin with [slashdot.org]. At the end of the day, the old formats are doomed to well deserved neglect, and there's no reason M$ could not just publish everything about them and let their former users translate things for themselves.

It's actually much worse than the/. article you linked to would suggest. That article merely suggests there are undocumented bits, but the truth is that a substantial portion of the documentation is flat out wrong. If you follow the documentation, I guarantee you that your file will not be readable in any version of Microsoft Office.

What do you mean "as poorly defined"? With the binary formats there was basically no documentation: now we have detailed vendor-supplied documentation of virtually the entire XML format.

As you will note if you follow the previously supplied link [slashdot.org], MSOfficeXML references the results of their old binary cruft without further definitions, which is no better than nothing at all.

If they really cared, they would reveal what they already know and quit keeping those old secrets. They don't and all their efforts are just so much PR, aka a big lie. You were lied to before and you are being lied to again.

Their "old binary cruft" preserves backwards compatibility. Are you against that for some reason? That's all I take away from that "analysis" of the format. Is there some sort of predisposition against protecting an investment in your world?

Their "old binary cruft" preserves backwards compatibility. Are you against that for some reason?

No, I think he is against the failure to document the expected behavior instead of merely mandating mimicing of legacy applications behavior without specification of what that behavior is.

One would facilitate implementation. One is a barrier to implementation. Microsoft, unsurprisingly, chose the latter, either through incompetence or desire to produce a standard that could not practically be implemented by third parties.

I fail to see how it can't be. If that's the "price" you need to pay to get rid of the "secret" implementation, then you need to decide if it's worth it. Microsoft can't just throw away billions of existing documents out there to make a few people happy.

Besides... the whole idea of using XML for this is brain dead. ODF or OOXML or whatever, it's stupid and shortsighted. A binary format that was well documented would have been much better. Regardless of standardization or openess, ODF and OOXML seem like s

Their "old binary cruft" preserves backwards compatibility. Are you against that for some reason?

No, it was designed to break compatibility with other Word Processors back when their was competition on M$ platforms. They are abandoning those formats now and may or may not preserve that compatibility. It's obvious to me as a user that they did not care much about it in the past, because old documents lost their format regularly before I decided to not use stuff from M$.

I'm sorry, unless you're making one of your "I hate M$ and so should you" leaps of faith, you'll have to go back and show me where I said or implied that.

Microsoft's interests are parallel to my own insofar as their software does what I need it to do. Otherwise I wouldn't be their customer. Or Sun's. Or IBM's. I find that mixing business with religion just doesn't work. Best tool for the job and all that.

I find that mixing business with religion just doesn't work. Best tool for the job and all that.

"Best tool for the job" is only one tool for the job, and it's not a very good one for long-term sustainability. Though Microsoft's interests may parallel yours in the short term, you must consider that their interests in the long term are unrelated at best or opposite yours at worst in the long term. No long-term profit for non-monopolists and all that.

you must consider that their interests in the long term are unrelated at best or opposite yours at worst in the long term

It's been fine so far - 16 years and counting. I have a real hard time with these "in the long term you're screwed" when the alternatives to Microsoft's software didn't exist even three years ago. In this industry 16 years is as good as it gets. Isn't RedHat obsoleting their RHEL installations after three years now? Yeah, that's where I want to go, away from the "evil" Microsoft. And th

You have pointed out that there are a few, legacy, parts of the specification that aren't defined. What we have for XML is several thousand pages of detailed specifications, compared to close to nothing before. How is that not better?

Soon enough M$ reps will be FUDing it up with the same old noise they've always made about "partial" implementations. All day long, you can hear them say that Open Office is not up to snuff because it does not "properly" translate all of those crusty old formats. Their new XML will be much the same, so it's no better.

If they get an ISO stamp, it will be worse because they can claim some kind of reputability and "openness" that they don't deserve.

Since you can't enforce these standards legally, you have to have these sorts of organisations that at least try to get some sort of consensus. After they've agreed on a standard, that can then become part of the conversation between different companies. "Can you implement standard X" instead of "What exactly do you do?"

Even if these standards have no "teeth", it is still hugely useful that they exist. Not all become what is used, but many do. Remember, HTTP and TCP/IP are such standards. They have caught

Even if these standards have no "teeth", it is still hugely useful that they exist.

Only if they are minimal, complete and unambiguous. In other words, only if everyone implementing the standard will follow the same conventions in practice. Since Microsoft's XML "standard" is neither complete nor unambiguous, it's worth about as much to anyone else as a patent dressed up in obscuring legalese, and any standards body worth its salt should reject it.

"despite the detailed complaints from national standards bodies." [...] So what is the point of these national standards bodies? Standards without a method of enforcement, are called "suggestions".

It depends on what the complaints actually were and how legitimate they are. I'm certain a lot of them were variations on "Micro$oft is teh SUX0R". There might have been some reasonable ones as well, but just because someone complains, doesn't mean the complaints are valid.

Thank you for clarifying that but what was your point and what did you mean? Your guess is that someone guessed? I was under the impression that complaints were filed and open to review as per the article. Your point is that you guess that someone was probably somewhat, or somehow pretending to have complaints?

As per the article the complaints were "detailed" and were filed by "national standards bodies". "I'm certain" that you assumed.

Thank you for clarifying that but what was your point and what did you mean?

My point is that people seem to think that just because they get complaints, then somehow the standard organization shouldn't move forward (or shouldn't fast track the standard). I would be surprised if anything with Microsoft's name didn't get complaints.

Oh no... They have teeth, they just didn't have the chance of using it yet.

ECMA submitted the standard for ISO. ISO can't really edit it alone, since it would ceasse to be an ECMA standard, and as it is already a standard, it goes to fast tracking. Then, the draft goes to the members, so they can comment on it, and everybody can create a better standard toghether.

We are here now. ECMA simply refused to improve its standard to meet ISO expectations. ISO could take tha long route, and disscuss the subject f

Assuming that the groups that had all the problems with it are not swayed by something between now and then, the end result looks a bit more like it would be a rejection than an approval... and if it's an approval, it will be a squeaker, not a landslide victory.

That said, it should be noted that the MSOXML does not fully expand out the data. When you read the article, you find that there are still things that are binary-encoded and proprietary.

Fast tracking only shows how much push they have and gives them more time to try again if it gets shot down. Reviewers should be respected, given the time they ask for and listened to when they finally form opinions.

What's to say they won't go and join the member organizations in countries that require unanimous votes, regardless?

If you've read the article, unless those nations have a greater-than-five-month waiting period, they'll go and join up in those countries, and end up causing a non-unanimous vote such that the member nation ends up with an "abstain" instead of "no." This is a tactic they've used in the past in order to get some of their stuff through.

Well, I suppose a standard could be created based on the documentation from Microsoft. It is hardly an independently-implementable standard, however.

Alternatively, a workable standard that is truely interoperable could be accepted that is not anything Microsoft would implement.

I seriously doubt there is much middle ground between these two positions. Microsoft is after all in a position to just say no.

The real problem is that even with (X)HTML/CSS it is not currently possible to take two different implementations and produce the same printed output from the same source material. This is a far, far simplier standard than anything being discussed as a word processing format, and yet there is no common implementation. I am not even sure there is today an accepted "correct" implementation for printing HTML.

How are we going to have a multi-implementation standard for word processing that produces identical formatted documents? I would say it is clear we are not going to have this. This makes the "standards" process a joke.

If you somehow believe that the "presentation" can be separated from the "content" in important documents, you probably need to have more familiarity with government processes.

(X)HTML/CSS were not intended for print. Word with doc "standard" has trouble printing the same document on different printers from the same computer. The closest are Postscript and PDF, but even then you sometimes have font problems, color issues and more minor trouble.This ISO standardization is supposed to clear up this matter but only seems to bring in more confusion.

NeXT had Display Postcript which rendered close to true but had no interoperability with any other system.

The real problem is that even with (X)HTML/CSS it is not currently possible to take two different implementations and produce the same printed output from the same source material. This is a far, far simplier standard than anything being discussed as a word processing format, and yet there is no common implementation. I am not even sure there is today an accepted "correct" implementation for printing HTML.

HTML and CSS were never designed to display identically on different devices. In fact, they explicit

The only reason that Microsoft wants this to be a standard is to get past the proposed laws that specify that government documents use an open standard. That's why these proposed laws, like the one recently introduced in California, need to specify that the standard must have an open-source reference implementation.

Or, better, should specify that software acquired for use by public agencies must both be open-source and use open standard formats by a date certain, except where no suitable alternative to fill a need exists and sponsoring a conforming new system would be prohibitive.

I know no slashdoter wanted this (too much anti-ms in the air), but think of the bright side.

MS has the market by the balls with the only real competition being the WordPerfect suite...Personally I do not like it, but it is fairly widely used in School in Canada. Anything that allows Word documents to be a bit easier to convert to other formats is a good thing.

Having read TFA and the PDF of the ECMA responses [computerworld.com] to the complaints, i can see why they decided to fast-track it, many of the complaints by countries are thoroughly debunked as misunderstandings of the specification. The rest are supposed to be resolved during the 5 month process.

As for TFA, they started out talking about fast-tracking the standard, then went on about totally unrelated and unsubstantiated stories about intimidation.

I may be flamed for it, but i call FUD on the part of Groklaw for this "story", the process is working as intended.

Having read TFA and the PDF of the ECMA responses to the complaints, i can see why they decided to fast-track it, many of the complaints by countries are thoroughly debunked as misunderstandings of the specification.

That's fine, but it only takes one complaint ('contradiction' in ECMA parlance) to stop the process, and there was one such provided by three separate national bodies. It stated the objection, raised elsewhere in this thread, that elements in the standard such as autoSpaceLikeWord95, which basically state, 'do things like we did in this version of this application', are contradictory to the the very essence of a document standard.

ECMA's response is not at all satisfactory. First, they provide the self-serving argument that they're reproducing the state of the art, then they say that they can throw in any missing details later in the process, then they conclude with a statement that is patently absurd:

As already discussed, the OpenXML committee chose to take a different route in defining document settings. If,
however, it is decided that more documentation should be provided on the elements in question, or if the
elements should be removed from the standard, that is a more appropriate matter for the 5-month ballot, and is
not, in fact, a contradiction.

We can sum this up as 'We accept that nobody has ever done this before, but we don't think that contradicts other standards. Anyway, even if it does, let's just agree to talk about this later.' Ultimately, ECMA is saying, 'Whatever faults may exist, even if they're unprecedented, let's just get on with it. We'll figure things out as we go.' That is hardly what one would expect of any self-respecting standards body.

Having read TFA and the PDF of the ECMA responses to the complaints, i can see why they decided to fast-track it, many of the complaints by countries are thoroughly debunked as misunderstandings of the specification.

The document you've linked to there simply repeats all of the lies and half-truths that Groklaw and elsewhere have pointed out. For example:

Open and XML-conformant independence from proprietary formats and features

There is certainly no evidence for independence from proprietary formats and

Having read the ECMA response, I think that it should be taken as gospel. OpenXML should be ratified as a standard for "faithfully representing the majority of existing office documents in form and functionality", and it can therefore peacefully coexist with the use of ODF for all newly created documents. In fact, all of these countries are giving entirely inappropriate comments, because they seem to be thinking that this is a proposed standard for office documents, when it is actually a proposed standard f

I remember awhile ago an employee at Opera pointed out that using html and css would create a much easier to adopt document standard. Since it is well understood and universally used. There are a half dozen html renderer's that could all be used to read content on all platforms.

This has many advantages over everything that is being offered now. A universally viewable open well understood and easily learned document standard? That makes too much sense to go anywhere.

HTML and CSS are a great solution for screen displays, an OK solution for printing (assuming CSS 2.1). So, HTML/CSS would be a great solution for presentation software. But they are not particularly good at expressing structured documents like a spreadsheets, relational data and rich text documents. I don't seem how HTML tables would be a natural starting point for a spreadsheet, for example.

The original use of HTML was to create links to rich content, which in the case of CERN would be things like post

If people didnt jump on whatever the newest Microsoft software is they wouldnt get away with this sort of thing.

What? You mean that there should be some drawn-out process to keep the most-commonly-used XML format from being standardized?

MS's XML should be marked and tagged as standard ASAP -- that way, when Office 2010 rolls around, OpenOffice 3.0 can simply say "we put out docs according to MS's standard. If it doesn't work, it's THEIR fault."

MS's XML should be marked and tagged as standard ASAP -- that way, when Office 2010 rolls around, OpenOffice 3.0 can simply say "we put out docs according to MS's standard. If it doesn't work, it's THEIR fault."

The problem with Microsoft's "standard" is that in many places it says things like "do what Word 5.0.3 does in when in double-line-spaced mode" without saying just what that means. The specification for Microsoft's XML format is not in the standards documents, it exists in only one place - the source code for Microsoft Word. Making a fully compliant implementation of Microsoft's XML format when you haven't got access to the Word codebase is therefore virtually impossible.

That is true. It is however less of a problem for a program merely wishing to *write* a document that MS-Word will (well, let's be realistic -- SHOULD) interpret correctly.

True, there is a tag for "Do Line-spacing the way Word version x.y.z used to do it on a Mac" (with no further specification what exactly that was), but if you're just *writing* the files there's a simple solution to that: don't use that tag at all. (it exists only for backwards compatibility anyway, I very much doubt that it's possible to make a new version of Word write that tag if you're starting from a clean new document)

If you need to *read* the stuff though, you're out of luck, because you can bet someone is gonna complain if you're able to correctly read only 99% of all Ms-office documents, despite the documents themselves being the insane ones.

Have you seen any ISO 9001 certificates?
The idea of going ISO is to be able to certify and advertise you compliance.
There is no 97% compliance certificate!

The management systems, starting with 9000 and spanning things like 14001 environment, 18001 safety/health and 27001 security, have audit as an integral part of the process. That's not true of the other ISO standards: there isn't a process for having your `ISO' C Compiler certified, and there isn't an audit process. There are test suites, but no

An all-new format that supports backward compatibility with an older and supposedly unrelated format? Are you reading what you're writing?Backward compatibility shouldn't enter the specification at all. It's the seemingly endless instances of backward compatibility support that has made Microsoft's stuff the resource-sucking pig that it is today. Here, they have an opportunity to divest themselves from all that legacy crap and get neat, fresh and unified. They just keep playing the same endless games th

Actually, if Microsoft would have done it right, both loading and writing would be easy. Imagine Microsoft Word 2007 detecting a Mac Word 5.3 document (binary, evidently) that has odd margin handling. Instead of writing a tag "emulate-word-5-3-mac", it would write "margin="-77,3pt"

If you do this, the output and thus target format would just have the clean information for displaying. No "just do as if you are Word on Mac", but "compensate margins -77,3pt". That this was because it was created on a Mac o

The problem with Microsoft's "standard" is that in many places it says things like "do what Word 5.0.3 does in when in double-line-spaced mode" without saying just what that means

Isn't that just for use when converting documents from Word 5.0.3 format? New documents won't use that tag.

Compare to ODF, where key formatting parameters are left up to the application, so that if you had two completely independent ODF implementations, written just from the "standard", documents produced by one would would pr

Isn't that just for use when converting documents from Word 5.0.3 format?

No, it's for use when not bothering to convert documents from Word 5.0.3 properly. If you were really converting a document, you'd implement the behaviour of Word 5.0.3 using the new tags. If Word 5.0.3 in double-line-spacing mode did 1.97x line spacing and added a 0.05 inch extra margin at the bottom of the page, you should code that, not just have flag which says "be like Word 5.0.3". The place for details of legacy file formats like that is in a conversion tool, not the specification.

The problem with Microsoft's "standard" is that in many places it says things like "do what Word 5.0.3 does in when in double-line-spaced mode" without saying just what that means. The specification for Microsoft's XML format is not in the standards documents, it exists in only one place - the source code for Microsoft Word. Making a fully compliant implementation of Microsoft's XML format when you haven't got access to the Word codebase is therefore virtually impossible.

As it turns out OpenOffice has a similar feature the "config:config-item" XML property, and there are a number of these config properties that remain unspecified (from page 14):

The ODF committee chose to exclude the list of settings (many of which are commonly used in a variety of applications) from the ODF standard, which has resulted in a large number of separately defined application specific settings which is an actual barrier to interoperability. For example, the following are a small selection of properties that OpenOffice saves into ODF using application specific settings (all of which affect the display of the document):

That being said, OOXML is vastly better specified than ODF is. As I pointed out on my blog some time ago, it would not be possible to build a spreadsheet today using the ODF specification, too many details would have to be extracted from either the OOXML spec (oh, the irony!) or an existing implementation that was based on public information like the Excel documentation (Gnumeric, Open Office).

What's keeping it from being standardized? It turns out that the standards written are grossly inadequate for third parties to implement. If Microsoft authored a better specification, nobody would care.Not to mention, what does it matter if it's "standardized" (and by that I assume you mean accepted as a ISO standard)? It's already implemented in the next version of Office, which in a very real sense, makes it a defacto standard. What this is about is getting the format accepted by ISO. And the only reason

So that Microsoft can go to those governments that have declared that they will only use document formats that ate international standards and say "Look, look, ISO standard" (pointing to Open XML). "Now you can stay with safe Microsoft instead of going for that strange communist OpenOffice.org".

When it by no means is a standard others can implement without their blessing, then yes. There should be at minimum a drawn-out process to keep the most-commonly-used XML format from being accepted as a standard, at least until it is an actual standard...

The industry is fifteen years down the wrong path. We (many of us) tried to warn our nontechnical peers before things came to this point. We tried to express the benefits of a diverse field. We tried to illustrate the merits of alternative technologies. We tried to sing the praises of other operating systems and other companies. The sad fact is that computer technology was wrestled away from the true technologists who invented it and was thrust headlong to the public sector by the businessmen, politicians, stock brokers, and bankers who saw a massive profit potential in it but had no real knowledge or appreciation of the intellectual advancements which created it.

Billions of dollars in taxpayer money were funnelled, through government grants, contracts, and subsidies, into social circles and corporations who had demonstrated a willingness to put aside the morals and values of the true scientists in favor of ensuring their own priveleged paychecks, pensions, and long term profit margins. The American taxpayers subsidized the startup of the.com bubble, we paid for the infrastructure on which the rest of the internet was built, and we paid for the products, the software, and the services on the consumer end. Where, then, did the profits from the.com bubble go? The profits went into the hands of the same major investment groups who have been carefully profiling and controlling the market for generations--people who, when the.com bubble became the.com bust, shrewdly bought the real estate being sold by the common people seeking to ameliorate their losses (which had been carefully planned by those people who were now buying their real estate at dirt cheap prices). When America began to return to consciousness after the.com blackout we now find that the same real estate which we sold to keep ourselves from bankruptcy is being rented or sold back to us--as condos, apartments, are housing communities--at three, four, ten, even hundreds of times the cost.

The pyramid [slashdot.org] scheme [slashdot.org] is so beautiful we could almost cry for joy if we were on the financial winning side of it. As it is we have no choice but to cope with a world where Motorola is relegated to handhelds, HP has partnered with Compaq and become just another x86 retailer, and Microsoft holds a betting majority of the chips when it comes to influencing the direction of software development and globally recognized protocols.

As it is we have no choice but to cope with a world where Motorola is relegated to handhelds, HP has partnered with Compaq and become just another x86 retailer, and Microsoft holds a betting majority of the chips when it comes to influencing the direction of software development and globally recognized protocols.

That's not entirely true. There are people fighting back, you do have a choice. I know everyone hates it when you pull out the "Linux" card, but from my perspective it is a perfectly viable alter

The sad fact is that computer technology was wrestled away from the true technologists who invented it and was thrust headlong to the public sector by the businessmen, politicians, stock brokers, and bankers who saw a massive profit potential in it but had no real knowledge or appreciation of the intellectual advancements which created it.

All 6 of the complaints were about technical issues. The 1-month fast track approval is not the correct place to raise those types of issues. The only thing that can keep something from getting fast track approval is an objection that highlights why it conflicts with standard that has already been approved. None of the 6 complaints did this, so it was pushed through.They can of course, raise the same complaints during the 5 month ballot process, which is the correct time to raise such concerns. Although

There are only 30 members of the committee. From Computerworld [computerworld.com]:

Rajchel wrote that she decided to move Open XML forward after consulting with staff at the International Technology Task Force. She did not mention that the 6,000-page proposal, submitted by another standards body, Ecma International, had garnered comments and criticism from 20 out of the 30 countries sitting on the JTC-1 committee.

(which from an archival viewpoint is a good thing, the more ways we have of doing the same thing means a bigger safety net for our data)

Care to explain? Having multiple formats just means that you're more likely to pick the wrong format and end up without access to your data from new products in the future. Having multiple ways of doing the same thing only fractures the community doing the thing.