Microsoft’s “big” announcement: blah, blah, blah…

Everyone is simply buzzing with excitement – well O.K. maybe not.

Microsoft have today, made a “big” announcement on interoperability.

Here’s the press release.

Most commentators I have had chance to read so far on the ‘net, having re-read it a couple of times themselves are now getting the gist of it: ‘Nothing new here, nothing to see, just move along…’

The best remark for me so far is the highly damming comment from the EU commission as reported on the BBC’s website.

“The Commission would welcome any move towards genuine interoperability,” it said.

“Nonetheless, the Commission notes that today’s announcement follows at least four similar statements by Microsoft in the past on the importance of interoperability.”

Basically, all they have done today is to “announce” what the EU told them “do” to last September. Clearly the EU would like to see actions rather than words…

The timing of this announcement, so soon before the – oh-so-important – BRM in Geneva for their OOXML specification review is rather suspicious to say the least. Don’t let anyone have enough time to read it properly before meeting on Monday (25th Feb) but just in time so they get some nice PR to help them along.

Watch out everyone – this may well just be another part of their Jihad.

The Deprecated “Smoke Screen” of MS Office Open XML (OOXML)

BSI British Standards states:

“… a standard is an agreed, repeatable way of doing something. It is a published document that contains a technical specification or other precise criteria designed to be used consistently as a rule, guideline, or definition. Standards help to make life simpler and to increase the reliability and the effectiveness of many goods and services we use. They are intended to be aspirational – a summary of good and best practice rather than general practice. Standards are created by bringing together the experience and expertise of all interested parties such as the producers, sellers, buyers, users and regulators of a particular material, product, process or service.”

In an effort to win quick converts to its bid to have Microsoft Office Open XML (MOOXML) accepted as an ISO standard, Microsoft is deprecating parts of its widely-criticized MOOXML. But whatever the new Microsoft OOXML file format with deprecated parts will eventually look like (if such a format ever appears in an actual application), these cosmetic changes don’t really make a difference for Microsoft or the world. Neither Microsoft Office 2007 or the version after that will ever likely produce a standards-compliant format. Besides, OpenDocument has been around now for a few years and is becoming widely supported in industry. However, there has been no meaningful movement from MS towards support. Actions speak louder than words.

What is described in the ECMA OOXML specification is not what is currently implemented in MS Office 2007. The actual specification: says ECMA OOXML is a format that Microsoft Office 2007 can *read*. Note, however, that it is not the format that Microsoft Office 2007 is actually *writing* for example: The Scripts, macros, passwords, Sharepoint tagshooks, DRM and other tie-ins used by MS Office 2007 are not part of the ECMA OOXML specification. If you try encrypting a document in Office 2007, it is no longer even a zip file + XML at that point. There is no editor reference application for Office Open XML, so an application can send Office Open files to Microsoft Office, and Microsoft Office can open those files, but any edits are saved in a different format!

Launch Microsoft Office and try to save a file in the format specified by the draft standard at ISO. You can’t. There is no compatibility mode in Microsoft Office that limits input to the feature set specified in the official Microsoft Office Open XML draft ISO standard. Any suggestions of interoperability for anyone wanting to support the Microsoft Office Open XML specification is ridiculous, especially since Microsoft itself won’t allow its customers to write to that format.

Microsoft will NOT change its Office program to become compliant with ECMA . The marketing firms on retainer will simply advertise loud and clear that “Microsoft OOXML is now an ISO standard”, and will blur the differences it sees between MS OOXML, ECMA OOXML and ISO OOXML. This will do the trick for most people, who are not technical experts. But they will eventually get caught again in the confusion. Microsoft is not concerned about what the global community needs, but is acting strictly to protect its monopoly.

Deprecating some controversial issues shows some of the signs of the significant failures of the format. Shuffling chapters around and putting some parts in the annex is not the answer to technical shortcomings. Such aggressive proposals at this time, seem more geared to be for “Talking Points” only rather than the sincere interest in creating a truly open standard.

There are still major problems with the format as now proposed in its deprecated form, from cultural and linguistics adaptability problems, accessibility issues, to the reliance on the MS Windows product, the guidance to what is called the “DEVMODE” structure, increased Patent problems, added harmonisation and interoperability problems, such that third party implementation remains almost impossible. And there are many, many other problems with MOOXML as an ISO standard. And let us not forget the proposed format has never been implemented or tested. Indeed, one wonders if MOOXML can be tested or implemented by any vendor other than Microsoft. MOOXML is still far from achieving acceptance as a true standard.

The fact is that even MS Office 2007 itself has not implemented the initially proposed ECMA format. So it is more than apparent that the new “smoke screen” proposals will never be implemented or even if they can be, not even by Microsoft, let alone third party vendors. It also dooms all the .docx files out there already. Is MS ready to carry out a product recall or ready to develop another converter for this problem? Not likely.

Moving stuff into deprecated status does not ease the burden of implementing DIS 29500. The TRUTH IS that every application will need to support the deprecated features in order to read files with the deprecated features.

The legacy binary formats remain closed. If a file is one which was converted from an older format of Microsoft Office by DIS29500 and allowed to wrap the old file in xml, it remains unreadable for everyone else. OOXML is still a closed spec tied into to many proprietary formats.

ECMA 376 is a bomb disguised as a standard. It redefines functions and components just to retain ties to the undocumented legacy formats. Therefore a number of things that should be fixed by now, thanks to better engineering, and existing ISO standards, are left not only unfixed, but even perpetuated by ECMA376. Why? There is a difference between preserving old files and moving them to a new format with all the same internal bugs. In essence, Microsoft is shoving their own mistakes right down the throat of ECMA/ISO. Microsoft has the audacity to appear to be saying that the standard meets a different need, when all it seems to mean is : “we don’t wanna fix our bugs, because that would force us to use standards, and that is unacceptable to us.” Unfortunately, the new proposals illuminate this unchanged and obstreperous position.

Further more the proposed deprecated changes increases the already dramatic overlap with the established ISO standard for Office Documents. If creates new patent problems in such that now MS reserve the right to sue you if you implement any of the deprecated stuff moved to the annex of the proposed standard. It makes harmonization and interoperability worse than ever because without the code for interpreting the deprecated items, any file with deprecated data will be impossible to read properly. It is obvious, but despite the obviousness, the problem persists.

To the extent that Office 2007 will have to be changed, to the extensive coding work which would need to be done, don’t you think it is just wiser to reject OOXML as a ISO standard because it is not one, and for Microsoft to collaborate on the development of ODF and create one universal file format for everyone.

The Culture of Self Interest is not Open

ABOVE: Comes vs. Microsoft Plaintiff’s Exhibit. See original version here in PDF.

So let us be clear, an ISO standard should benefit everyone and should be developed by consensus for fair competition and through open participation for all to embrace, enhance and share. DIS29500 as now proposed still only serves the commercial interest of one vendor and will always only serve the interest of one vendor – Microsoft. This is the way the OOXML format was designed. It was designed to ferment their monopoly into the sun. Microsoft will make promises to the National Boards that it will fix the OOXML format “later”, but as this standardisation process has shown so far, Microsoft doesn’t keep promises.

Unless wasting time is part of the current marketing tactics used by Microsoft, the most advantageous action would be for that company to accept the standing invitation to collaborate on the development of the established standard, the OpenDocument Format, and to create one universal file format for everyone – the fundamental purpose of standardisation.

This article was originally written by Russell Ossendryver.

Big Blue on OOXML

Some will probably say “it’s about time too”…

IBM has made public an article written by Peter Seebach called “OOXML: What’s the big deal?”.

In it Peter explains in clear and unambiguous language why Microsoft’s OOXML document format (also know as DIS29500 or ECMA-376) is not fit to be an international standard.

Stating what has already been said many times before might be construed as boring or repetitive, but in this case Peter gives a refreshingly concise review and summary of the main issues. Many of which have been lost in the verbosity and plethora of opinion and conjecture that abounds on the web regarding OOXML.

Here are couple of salient comments from the piece:

There have been a number of technical complaints made about OOXML. Every one of them comes down to the same base complaint: Rather than specifying a reasonable common interchange format, OOXML specifies the whole feature set of Microsoft Office, down to bug compatibility. This creates a burden on other implementers which is simply unreasonable (and in fact impossible) to meet, while conveniently being precisely what Microsoft is already shipping. That raises a lot of concerns.

He goes on to examine three categories of “showstopper problems” and gives examples in each. The final category, “Unique Features”, is quite damming in it’s final analysis…

Probably the most famous example is one of the optional settings provided in OOXML. The setting is called “useWord97LineBreakRules”, and it specifies to use the line-break rules that were used in Word ’97 for East Asian documents. Much like the previous examples, this is of course impossible for anyone else to do, as no specification of these rules is provided. In fact, the OOXML standard even warns implementers not to implement this:

The OOXML standard’s guidance for useWord97LineBreakRules

[Guidance: To faithfully replicate this behavior, applications must imitate the behavior of that application, which involves many possible behaviors and cannot be faithfully placed into narrative for this Office Open XML Standard. If applications wish to match this behavior, they must utilize and duplicate the output of those applications. It is recommended that applications not intentionally replicate this behavior as it was deprecated due to issues with its output, and is maintained only for compatibility with existing documents from that application. end guidance]

This guidance is excellent. Given that there is no specification available of this feature, and it is deprecated, it makes all kinds of sense for people not to implement it. But wait; if it shouldn’t be implemented, why is it in the spec? Compatibility with existing documents is not a reason to add a feature to a standard aimed at interchanging data; users are worried about whether their text can be opened at all in another program, not whether every line break is in the exact same location!

This feature is in the spec because OOXML is not a document interchange format; it’s a careful, bit-for-bit, replication of Microsoft’s historical binary formats, wrapped up in angle brackets.

That’s a cracking analysis. OOXML is NOT a document interchange format. It’s MS Office binary wrapped in XML…

Peter’s conclusion says it all.

OOXML is a credible effort to solve a real problem: The problem of how to replace completely opaque binary files encoding ten years of accreted behaviour with partially-legible XML files encoding the same behaviour, down to the last bit. That problem, unfortunately, is not the problem of providing a usable, implementable, exchange format for office documents.

OOXML should not, and must not become an ISO standard. It is, as we have been saying all along, a proprietary vendor’s implementation of their proprietary document format. There will be only one beneficiary if this becomes a global standard, and it isn’t you or me…

Microsoft’s Jihad – Be afraid. Be very afraid…

PJ has done it again…

There is some material she has uncovered from one of the many previous cases against Microshaft that show just what kind of company it really is…

It is really mind boggling the depths to which they stoop to achieve “World Domination”. This is verbatim copy from Microsoft presentations and other internal material. [Emphasis mine]

Evangelism Is War

Our mission is to establish Microsoft’s platforms as the de facto standards throughout the computer industry. Our enemies are the vendors of platforms that compete with ours: Netscape, Sun, IBM, Oracle, Lotus, etc. The field of battle is the software industry. Success is measured in shipping applications. Every line of code that is written to our standards is a small victory; every line of code that is written to any other standard, is a small defeat. Total victory, for DRG, is the universal adoption of our standards by developers, as this is an important step towards total victory for Microsoft itself: “A computer on every desk and in every home, running Microsoft software.”

[DRG = Microsoft’s Developer Relations Group]

5: Jihad

A Jihad is a road trip. in which an evangelist visits a large number of ISVs one-on-one to convince them to take some specific action. The classic Jihad is one focused on getting Tier A ISVs to commit to supporting a given technology by signing the technology’s Letter of Agreement (LOA – see above).

A Jihad focuses on the Travelling Salesman aspect of evangelism. As in sales, the purpose of the exercise is to close – to get the mark the ISV to sign on the dotted line, in pen, irrevocably. Not to get back to us later, not to talk to the wife about it, not to enter a three-day cooling-off period, but to get the ISV to sign, sign, sign.

If the start of the meeting is the first time the ISV has seen the LOA, then he’s not going to sign it at the end of the meeting. Since we’re asking for a very serious commitment, we want the ISV to give their signing serious consideration. If the ISV cannot deliver, then his committing to deliver is worse than useless – the ISV’s participation may occupy one of a limited number of available slots, keeping some other ISV from participating.

• The ISV has seen the LOA at least a week before the Jihad visit
• The LOA is very clear about what exactly each side is promising to deliver, and when
• An Officer of the ISV’s corporation will be attending the meeting
• Microsoft’s Director of DRG has positioned the LOA with sufficient seriousness, in a cover letter or other communication in advance of the meeting
• You make it clear from the start that the purpose of your visit is to answer any questions that they might have, preparatory to signing the LOA while you’re there
• They understand that those who do not sign the LOA, are frozen out of all further information about the techology until it goes into public beta
• They understand (without being crude about it) that you will be making the same offer to their competitors
• You have T-shirts or other swag to give to those who sign. lt’s amazing what some people will do for a T-shirt.

This is absolutely Amazing. Not only is it evangelical in the same way Al Q’aeda is, but they also manage to sound like the guys who come into our houses here in the UK and try to sell double glazing or a new conservatory.

The elements of the evangelical infrastructure – conference presentations, courses, seminars, books, magazine articles, whitepapers, etc. – should start hitting the street at the start of the Slog. They should be so numerous as to push all other books off the shelf, courses out of catalogs, and presentations off the stage.

Working behind the scenes to orchestrate “independent” praise of our technology, and damnation of the enemy’s, is a key evangelism function during the Slog. “Independent” analyst’s report should be issued, praising your technology and damning the competitors (or ignoring them). “Independent” consultants should write columns and articles, give conference presentations and moderate stacked panels, all on our behalf (and setting them up as experts in the new technology, available for just $200/hour). “Independent” academic sources should be cultivated and quoted (and research money granted). “Independent” courseware providers should start profiting from their early involvement in our technology. Every possible source of leverage should be sought and turned to our advantage…

…A stacked panel, on the other hand, is like a stacked deck: it is packed with people who, on the face of things, should be neutral, but who are in fact strong supporters of our technology. The key to stacking a panel is being able to choose the moderator. Most conference organizers allow the moderator to select the panel, so if you can pick the moderator, you win. Since you can’t expect representatives of our competitors to speak on your behalf, you have to get the moderator to agree to having only “independent ISVs” on the panel. No one from Microsoft or any other formal backer of the competing technologies would be allowed – just ISVs who have to use this stuff in the “real world.” Sounds marvellously independent doesn’t it? In fact, it allows us to stack the panel with ISVs that back our cause. Thus, the “independent” panel ends up telling the audience that our technology beats the others hands down. Get the press to cover this panel, and you’ve got a major win on your hands.

Here’s what they think of you if you are one of Microshafts ISVs.

Now call me old fashioned if you will, but the fact that they actually wrote this stuff down is beyond me.

Thanks to Groklaw, you can download the complete documents from here: http://www.groklaw.net/pdf/Comes-3096.pdf in ISO-32000 (PDF) format. Yes that’s right; PDF went through ISO very smoothly last December with barely a murmur. Funny how OOXML hasn’t. Well, actually, perhaps after reading the crap that spews forth from Microsoft it isn’t…

Do you really want them to own an International Standard? If DIS29500 does get approved next month, the ISO will become just another “trophy” of their war machine. No corporation, however big or powerful should be able to corrupt the global standards process as Microsoft have tried to do.

OOXML is already obsolete.

This is a great piece of analysis of the status of DIS29500. Included here in it’s entirety, courtesy of the Free Software Foundation Europe.

DIS-29500: Deprecated before use?

[Also available as PDF (1.4M)] When ECMA submitted MS-OOXML as ECMA-376 to ISO for fast-track approval, several countries¹ criticised overlap with the existing ISO standard ISO/IEC 26300:2006, the Open Document Format (ODF).In its February 2007 response, ECMA admits that MS-OOXML addresses the same high-level goals of representing documents, spreadsheets and presentations as ISO/IEC 26300:2006, but maintains that the standards meet different user requirements. This is clarified by ECMA’s statement that the explicit design goal for ECMA-376 is to preserve idiosyncrasies from Microsoft’s proprietary legacy file formats. This statement was included in the ECMA response on January 2008 to 113 comments² made by national bodies during the 2 September 2007 ballot, as well as its 14 January 2008 proposed Disposition of Comments.Considering that alleged preservation of idiosyncrasies is the stated reason for the entire DIS-29500 ISO process, FSFE considers it worthwhile to investigate this claim in greater depth.

The preservation of idiosyncrasies is a questionable reason for an international standard. The goal of standardisation is to provide consistency and to remove idiosyncrasies, not to perpetuate them. By aiming to preserve idiosyncrasies, the best achievable outcome is good documentation of incompatibilities. When it became clear that the main purpose of DIS-29500 was the documentation of idiosyncrasies, the process should have stopped. That it did not indicates a lack of internal structures in the fast-track procedures to prevent abuse of the international standardisation system.

Analysis of DIS-29500 by the national standardisation bodies quickly revealed that information to preserve proprietary legacy formats was referenced in the specification, but the specification of these formats was missing. So although the preservation of idiosyncrasies was the declared design goal and the reason for the creation of DIS-29500, this information is missing from the 6000+ page specification.

Microsoft recently deprecated its legacy file formats and as part of its response to criticism in the DIS-29500 process announced to finally make documentation of these formats available under the Open Specification Promise just before the BRM. Although there will not be enough time for analysis of comprehensiveness, quality and fidelity of that documentation for purpose of the BRM, it seems likely that Microsoft will declare this a satisfactory response to the question of missing specification in DIS-29500. It would however be premature for national bodies to accept this assertion in blind faith – in particular as publication will take place outside the ISO scope and is subject to all legal concerns regarding the Open Specification Promise.

Simultaneously, ECMA addresses this in Response 34 of its proposed Disposition of Comments by removing all references to idiosyncrasies from the specification and placing them in a newly formed Annex for deprecated information. With the removal of this information from the DIS-29500, the design goal of MS-OOXML can no longer be met. The entire specification has therefore effectively become obsolete.

Analysis has shown before that MS-OOXML is covering the same functional space as ISO/IEC 26300:2006 and is unnecessary. It was ECMA which insisted on backward-oriented documentation of idiosyncrasies being a sufficient motive for ISO to ignore the good practice of forward-oriented standardisation. But even by ECMAs own criteria the rationale for DIS-29500 has been deprecated.

In essence: Response 34 of the proposed Disposition of Comments effectively contradicts and invalidates Response 31, which cites preservation of idiosyncrasies as the primary design goal and reason for DIS-29500. It also invalidates ECMAs February 2007 response to similar criticism.

No implementation of DIS-29500

Because there is no justification for the standardisation of DIS-29500, its approval places an unnecessary cost on competition in the IT sector, resulting in artificially higher prices for end users.

Furthermore, the ongoing standardisation process increasingly modifies what started out as a documentation effort for Microsoft’s current default file format. The implementation is already being shipped for some time, and updating the product with the various improvements made to DIS-29500 would result in incompatibility of next year’s version of Microsoft Office with the files written by today’s version. Microsoft itself maintained this as an argument against these suggested changes during the international review phase.

With more than 2,000 pages of proposed Disposition of Comments and Microsoft as the only party with commercial interest in DIS-29500, it seems likely that we will see significant differences between the DIS-29500 specification and the MS-OOXML implementation, which will nonetheless claim implementation of DIS-29500.

Verification of this claim and ensuring fidelity of written data against the DIS-29500 will be an extremely costly exercise for all users of MS-OOXML. Because there will only be one alleged full implementation available, users will need to carefully compare their binary files against the DIS-29500 specification to protect fidelity of their data.

Microsoft and ECMA are in fact already using this strategy in their current responses to criticism by listing applications that seek compatibility with Microsoft Office 2007 as implementations of DIS-29500. Even where not sub-contracted by Microsoft, these applications certainly use DIS-29500 for guidance on how to implement the current Microsoft file format, but their benchmark for success is not faithful implementation of DIS-29500, it is binary compatibility with Microsoft Office 2007.

It should be noted that a similar situation could never arise with ISO/IEC 26300:2006 (ODF) because it already has several independent implementations. Files written by one application need to be readable by all others, otherwise there is a problem with fidelity in at least one of the applications. Because there is a wide range of applications and users for ODF, such incompatibilities will be detected easily. A diverse user and application base is the best insurance against creeping legacy lock-in.

Remember ECMA-234?

There is no need in the marketplace for ECMA-376, the specification does not deliver the promised preservation of idiosyncrasies, and there is no commitment by Microsoft to implement the outcome of the DIS-29500 process faithfully for a meaningful period of time. Does anyone remember ECMA-234, the “Application Programming Interface for Windows (APIW)”?

This ECMA standard was also put forward as standardisation of the Windows operating system with much the same promises that are being made for ECMA-376 today. It was deprecated just after ECMA-234 was finally standardised when Microsoft published Windows 95, which completely ignored the existence of ECMA-234. Microsoft’s product decision made ECMA-234 obsolete and turned the entire specification into a huge waste of collective effort. Without a binding commitment by Microsoft to faithfully implement the outcome of DIS-29500, the current process is promising to go down the same route.

It seems that ISO, its national standardisation bodies and hundreds of standardisation experts around the world are essentially being used for a rather costly product marketing exercise. The question is whether ISO should allow itself to be used in this way.

If it becomes common practice to standardise for promotional effect and then ignore, ISO might find itself deprecated in the area of Information and Communication Technologies.

FSFE would consider this too high a price to pay for approval of DIS-29500.

Related reading

• Six questions to national standardisation bodies
• The Converter Hoax
• Questions for Microsoft on Open Formats

---

[1] Australia, Canada, Denmark, France, Germany, Japan, Kenya, New Zealand, Norway, Sweden, Singapore, and the United Kingdom.

[2] BR-0002, CL-0057, CL-0058, CL-0059, CL-0060, CL-0061, CL-0062, CL-0063, CL-0064, CL-0065, CL-0066, CL-0067, CL-0068, CL-0069, CL-0070, CL-0071, CL-0073, CL-0074, CL-0075, CL-0076, CL-0077, CL-0078, CL-0079, CL-0080, CL-0081, CL-0082, CL-0083, CL-0084, CL-0085, CL-0086, CL-0087, CL-0089, CL-0090, CO-0081, CO-0082, DE-0114, DK-0004, DK-0005, GB-0136, GB-0137, GB-0138, GB-0140, GB-0141, GB-0142, GB-0143, GB-0144, GB-0145, GB-0146, GB-0147, GB-0148, GB-0149, GB-0150, GB-0151, GB-0152, GB-0153, GB-0154, GB-0155, GB-0156, GB-0157, GB-0158, GB-0159, GB-0160, GB-0161, GB-0162, GB-0163, GB-0164, GB-0165, GB-0166, GB-0167, GB-0168, GB-0169, GB-0170, GR-0094, GR-0095, IR-0008, IR-0010, IR-0011, NZ-0015, NZ-0016, NZ-0017, NZ-0018, NZ-0019, NZ-0020, NZ-0021, NZ-0022, NZ-0023, NZ-0024, NZ-0025, NZ-0026, NZ-0027, NZ-0028, NZ-0029, NZ-0031, NZ-0032, NZ-0033, NZ-0034, NZ-0035, NZ-0036, NZ-0037, NZ-0038, NZ-0039, NZ-0040, NZ-0041, NZ-0042, NZ-0043, NZ-0044, NZ-0045, NZ-0046, NZ-0047, NZ-0048, US-0096, US-0097, US-0098

To top

Copyright (C) FSFE. Last changed: 2008-02-18 08:33:49 (reinhard) [XHTML]
Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
Please report problems with this page to webmaster at fsfeurope.org.

OOXML: In Trouble Down Under

ITWire are carrying a news story from a couple of individuals involved with Standards New Zealand (SNZ). [Updated]

It would seem that some of SNZ’s advisers aren’t happy to say the least:

Don Christie, president of the New Zealand Open Source Society and a member of the Standards NZ (SNZ) OOXML Advisory Committee, says: “It is the view of the NZOSS that Microsoft and ECMA have failed to provide quality responses to SNZ comments. Even where they have supposedly ‘agreed’ with the comment the actual resolution has either introduced more/different problems or simply made the original item ‘unspecified’.”

Please ensure that your local NB is aware of their position after the SNZ carried out an excellent technical review and analysis during the initial fast-track review period. As we know already there are many NBs (National Bodies) which, surprisingly, upgraded their status just before September’s vote and, rather amazingly for a 6000+ page specification found no fault whatsoever and voted YES with no comments.

A comment from Franco Merletti on Andy Updegrove’s blog summed up this very well:

Maybe they can ask some people at the ISO National Bodies of Cyprus island, Jamaica island, Malta island, Cote d Ivoire and Lebanon, what caused their “sudden” motivation to ask (and get) ISO JTC1 P-member status a few days previous to DIS 29500 September/2007 ballot closing…

… just to vote unconditionally yes to +6000 pages of a notably flawed specification ( which until now achieved an outstanding mark of +3000 observations and +2000 quick-fixes/deletions/deprecations with only a few months of a rushed review and which final proposed text remains undefined ) generated in less than 1 year in a closed, not traceable nor accountable process at an ECMA Technical committee formed and lead by Microsoft.

I wonder how much technical review meetings took place at this national bodies to review DIS 29500 ( any minutes of this meetings? ) and what caused their unprecedented interest in Document Description and Processing Languages standards related to structured markup languages (specifically the Standard Generalized Markup Language (SGML) and the Extensible Markup Language (XML)) in the areas of information description, processing and association ( ISO JTC1 SC34 area of interest ).

I don’t want to be disrespectful with this countries, but i don’t consider standards and standardisations as a “game to win” ( it seems that some corporations have this point of view ).

I see here an amazing lack of respect, because many responsible JTC1 P-members ( with background and expertise in this field ) did a lot of *hard* work to review DIS 29500 to decide if it has the technical merits to be an ISO fast-tracked standard ( i.e: UK BSI [1], USA Incits/V1 [2], Japan, Canada [3], China, India, France [4], etc. ) and this other national bodies just seems to be pawns in the game, leaving the technical work aside.

Wake up ISO, wake up end users ! demand quality in standardisation ! Money shouldn’t buy standards.

franco merletti
[1] http://www.xmlopen.org/ooxml-wiki/index.php/DIS_29500_Comments
[2] http://www.ibiblio.org/bosak/v1mail/
[3] https://forums.scc.ca/forums/scc/dispatch.cgi/public/docProfile/100009/d20070504104953/No/t100009.htm
[4] http://iso-vote.com/afnor.html

The NBs that care so much, and have worked so hard to try and create a usable specification from this mess should be applauded. But their work should also be explained and reviewed by those NBs that found little or no fault with the initial proposal.

If they are struggling with the enormity of the task, we have established dis29500.org to help them. Take a look and help to verify ECMA’s responses.

ECMA, the organisation responsible for actually pushing this standard through ISO, have yet to release the new specification, based on the analysis and examination of the original 3522 comments submitted. The new proposal will be significantly longer than the original and is supposed to be voted on before the end of March. There is NO WAY that a comprehensive review of such a large specification can be done in this time frame. ECMA should withdraw their application fully and re-submit when they think they have a decent proposal. And they should not try to fast-track it either.

Christie says that responses have often been of poor quality. “If we were to extrapolate (the) poor quality of responses we have seen to the 54 Standard NZ comments to those of all the other NBs then we can only conclude that the result is probably a worse mess than the document we reviewed last August. Of course, that is conjecture because ECMA have yet to release the revised document, despite having made assurances that they would have done by now.”

How can any non-partisan NB vote unreservedly yes when there are standards bodies with exemplary reputations having found so many errors and inconsistencies in the same specification?

ISO Standards are for the benefit of us all. They should and must not be used for the benefit of one company so as to retain it’s Monopoly. Vote NO.