Open XML BRM – A Response To Bob Sutor’s Assertions


On November 15, Bob Sutor over at IBM posted an opinion on the ballot resolution meeting that I think is fundamentally misleading, but also raises some valid questions deserving consideration by all parties. To be clear, I think countries who voted no should carefully consider the technical work done leading up to the BRM and will hopefully move their votes to "yes." Obviously, Bob takes a different point of view. 

The posting will be organized by my paraphrasing points made by Bob (in black text) and my responses to them (in blue text). 

The BRM will result in a changed specification - those changes may themselves result in new problems.

Section 13 of the JTC 1 Directives discusses the BRM and make it clear that the whole point of the BRM is to change the specification in the interests of improving it and driving greater consensus for adoption. That is the point of the comments that are submitted, that is the point of having an Editor, that is the point of all the technical deliberations. In fact, IBM (whom Bob is representing in this discussion) was so good as to dedicate more than a year of work in reviewing the spec and submitting comments with recommended changes. It would seem inconsistent to now say that the disposition of comments somehow runs counter to the goal of having a quality specification or to cast a negative spin on these comments.

I know that the Project Editor is being very conscientious about the quality of the technical work done in the dispositions. The work of the Editor and TC45 is to improve the existing specification, not make a new specification. Clearly, the dispositions should be considered carefully by all parties. Yet, all parties should be interested in seeing an improved specification. (That was, after all, Rob Weir's justification for submitting so many comments - apparently IBM wants it both ways.)

The specification is long, there are thousands of comments, there is no way for a national body to consider the dispositions in the time they have.

IBM (read Bob) does not want you to notice that at the time of the Open XML (DIS 29500) vote last September, 87 national bodies had spent 5 months preparing comments - and most submitted proopsed dispositions to resolve their comments, as prescribed by the JTC 1 process. By the time of the BRM there will have been an additional 6 months of technical discussion/review and in total, more than a year of consideration of Open XML by national bodies since the DIS was submitted to JTC 1. More than that, there was another year of work done on the specification in Ecma TC45 and its submission to the Ecma plenary (where IBM chose not to join the TC and had the opportunity to review the spec for the plenary, and was the only Ecma participant to vote against in the plenary).

More importantly, there are waves of dispositions (comments and responses) being released for NB consideration in the months ahead of the ballot resolution meeting. This is coupled with the fact that the Project Editor is actively engaged in conversations with implementers and NBs around the world so that the dispositions are discussed in a professional manner in accordance with JTC1 Directives.

I do agree with Bob that the size and scope of the work is a serious engineering undertaking, and one that highly qualified people are working on - including IBM's own engineers and paid consultants (who are most certainly diligently working through the comments in order to block the spec - a highly unusual JTC1 practice, but that is for another time).

There are questions about the BRM process, attendance, time to consider all comments etc. - the process is bad.

Before you go too far on anyone else's blog - read this - it is the FAQ from the BRM convener. There is no process irregularity involved with the BRM whatsoever. IBM wants it both ways in Bob's argument. First, saying the process is broken, and then later saying that the process should be kept pure.

Some key points about the BRM:

  • The BRM is NOT another vote - it is an opportunity for comments to be addressed, considered, and changes made to the spec by the Editor with the intent of improving the specification.
  • NBs may reconsider their position on the specification within the 30 days following the BRM and may - if they choose - change their vote.
  • BRM will be 5 days, held at the end of February
  • BRM will be limited to the number of seats available (120 is the number stated)
  • NBs who voted "no" are highly encouraged to attend
  • The size of a NB delegation will be limited due to overall space availability - but the NBs may petition for the number of seats they would like to fill

The last item under this section is one that Bob raises that is worth considering. How will the BRM possibly move through 3000+ comments and dispositions in just 5 days. First, this is a technical discussion driven by engineers - a breed of people particularly adept at dealing with problems like this. The Editor is grouping comments and organizing them in a way that makes sense. Remember, IBM submitted most of the comments in most of the countries anyway - so a significant percentage of the comments are similar if not the same. That said, professional standards work by the Editor and TC45 (and the Convener) will make sure that all parties recognize that their issues were considered and included in the disposition. The 5 days will be structured to be productive and, hopefully, conclusive. I would hope that IBM is not planning to purposely derail conversations in order to create a process failure. That would be unseemly, no?

If you are not satisfied for any reason, vote against Open XML. The specification should be perfect or you should reject it. 

This is a rather broad claim, and useful if you are seeking to block the adoption of the spec. But, it happens to be contrary to not only normal JTC1 practices, but it is completely out of line with IBMs own experience on ODF.

Specifications in standards are not perfect. I'll repeat that so that I'm clear. Specifications in standards are not perfect. In fact, they are expected to be living documents that improve over time. This way, they are applicable to implementers and are able to mature as technologies do. Otherwise, you would have a whole bunch of obsolete specs being approved and never used.

Let's take ODF for example. ISO/IEC IS26300 (ODF 1.0 released from OASIS in May 2005) is no longer a valid specification for the market. OASIS has been significantly adding functionality to that specification and has since gone to version 1.1 and now 1.2, and is now working on 1.3. Hmmmm. So, was ODF really too immature for international standardization when it went through? Shouldn't it now be submitted as either an "amendment" (the JTC 1 term for a major revision to an international standard) or a whole new spec? My point is, ODF is a living document that is improving as IBM and others continue to invest in it. Ok - I have no problem with that. But, this makes the point that there are elements to any spec that goes through the JTC1 process that are not perfect, and need improvement. Those elements DO NOT mean that the spec should be rejected out of hand. Thus, you have both comments and a BRM process to resolve them.

Don't set a bad precedent with this specification.

Open XML has received more scrutiny and dedicated engineering attention than any specification in JTC1 (if not ISO or IEC) history. The Ecma specification that is the basis for the Draft International Standard is seeing broad adoption with multiple independent implementations. The implementers are saying that the specification is incredibly well documented and enabling them to build quality, viable solutions that are solving customer needs while opening new revenue opportunities for them.

Rather than the War and Peace analogy that Bob references, it might be better to harken back to OSI and TCP/IP as the analogy. It is worth recalling that the IBM-promoted OSI specification was NOT broadly adopted, while the market-driven adoption of TCP/IP won out.

Ok - back to all black text:

This blog is not about me and Bob, it is about IBM and Microsoft having differing views on the BRM - so let's keep the comments focused on the substantive issues rather than about the people (thx). I agree with Bob that the sheer volume of technical work around Open XML heading into the BRM is daunting. But it is not insurmountable, and it is being handled in a professional and thorough manner. All parties involved should be pleased with the amount of work going into making this specification better. The irony here, to me, is that Open XML is already better because of this with or without the ISO imprimatur. It will be a more formidable competitor in the marketplace from all the help IBM has given it. Rather thoughtful of them I'd say.

It is going to be an interesting few months leading into February.

Comments (16)

  1. Mike Brown says:

    >> [ODF] has since gone to version 1.1 and now 1.2,

    >> and is now working on 1.3. Hmmmm.  So, was ODF

    >> really too immature for international standardization

    >> when it went through?

    No.  And you’ve already explained the reason for the later releases when you said "OASIS has been significantly adding functionality to that [ODF] specification".

    Is that what you’re doing now, with OOXML?  Adding new functionality?  No, it isn’t, is it.  What you’re doing now is (hopefully) fixing all the errors in the OOXML spec as it is currently described.  The errors that should have never been eliminated by Ecma before the spec ever got near the ISO Fastrack process.

    Although thinking about it again, I guess you could say, at a stretch, that the ability to handle a date before February 29th 1900 (not a real date, anyway) *does* count as new functionality, because hey, it’s something that OOXML sure couldn’t do previously!

    Cheers,

    – Mike

  2. An interesting and useful rebuttal, although I don’t agree with all points.  I do agree that the idea that the spec should be "perfect" or you shouldn’t vote for it is ridiculous, and Bob should have known better than to say that.  What he should have said was closer to "If you are not satisfied with the disposition of a critical point, vote against the spec instead of believing assurances that the problem will be fixed later".  There is no doubt that virtually any standard will grow and improve, but it is easier to add than to change.  Thus, most changes in ODF have been to add to the specification.

    Again, I think that you are correct that we should go into this with a positive "can do" attitude, but I also think you minimize the hurdles.  This has been a very heavily scrutinized spec, but partly because the original creation was flawed in some serious ways.  That does not mean the spec can’t be improved, but it does mean that it may be very hard to tackle enough issues to produce a spec of sufficient quality.  Possible, just very difficult.

    Finally, though, I must object to the grandstanding in your statement "I would hope that IBM is not planning to purposely derail conversations in order to create a process failure."  I have seen no signs of such activity, and this seems like the worst kind of rumor mongering.  Microsoft’s hands are not so clean that they should be trying to besmirch others.  I also object to the continued emphasis of IBM vs. Microsoft.  There are many, many interested parties besides those two corporations, and you belittle all contributions on both sides of this issue when you ignore them all.

  3. Après la FAQ du BRM DIS 29500 (Open XML) mis à disposition sur le site de l’ISO et la mise à disposition

  4. hAl says:

    It is typical to speak about 3500 hundred comments when IBM is responsible for about 2000 instances of them in about an average of 10 identical or near identical copies per comment.

    Since IBM is responsible for over half of the submitted comments they should not now state that the proces is wrong as they obviously tried to manipulate the proces to their advantage by getting those national bodies to submit their comments where it would seem logical that only the US (being the home of IBM) would have send in the comments.

  5. Fernando says:

    Ben Langhinrichs, the IBM partner, sees no signs of IBM trying to derail the Open XML standardization process. Why am I not surprised?

  6. hAl,

    well, it’s the "6000-pages rethoric" all over again. Talking about numbers adds absolutely nothing of value to the discussion if you cannot qualify what you are concerned about.

    Also – it would be nice if everybody would accept, that not all comments are equally important. Of course there are show-stoppers with regards to VML etc, but take a look at the Danish comment DK081 page 32 in http://www.ds.dk/_root/scripts/getmedia.asp?media_id=2791. I wonder how many of these are in the 3500 remaining comments.

    BTW, http://www.ds.dk (Dansk Standard) is the Danish mirror of JTC 1/SC 34

  7. Luc Bollen says:

    @hAl :

    "Since IBM is responsible for over half of the submitted comments"

    I don’t see how IBM could have a ‘responsibility’ for the comments.  If you want to attribute responsibility, I think it would be more fair to attribute it to Microsoft or ECMA for most comments, since many of these comments are about errors in the specification initially written by Microsoft and then reviewed by ECMA.

    "it would seem logical that only the US (being the home of IBM) would have send in the comments"

    In fact, I’m surprised that there are so little duplicates : if there is an obvious error in the text (there are many, some of them reported by ECMA themselves), and if 87 NBs have done a careful review of the text, they should have ALL spotted the mistake and reported it.  At least the obvious textual errors should have 87 duplicates !

  8. Dave S says:

    Even if IBM wrote and delivered the exact comments submitted by representatives from many countries, it is unlikely all those country NBs would have done so were the comments clearly wrong and could be embarassing.

    Few countries have the technical expertise a company like IBM can bring to bear on the situation and no doubt appreciate a second opinion.

    Participating in and criticizing a process are not orthogonal. Were IBM to cease participation, any criticisms wouldn’t be ignored as originating from a non-participant?

    "The Ecma specification that is the basis for the Draft International Standard is seeing broad adoption with multiple independent implementations. The implementers are saying that the specification is incredibly well documented and enabling them to build quality, viable solutions that are solving customer needs while opening new revenue opportunities for them."

    The ECMA specification is being fractionally implemented by a few companies. Most of these ‘implementers’ are companies that previously had significant experience in implementing the previous version(s) of Microsoft Office products – Datawatch (Monarch), for example, is a long time Microsoft supporter.

    "Quality"? "viable"? If the companies involved were producing garbage solutions and were losing money, would they risk the loss of customers or investors by so saying?

    As an engineer I have seen little quantitative information about the benefits of MSO-XML, but I have seen that Zip compression of the previous formats produces files that are smaller than those in MSO-XML format.

    Had MS allowed for an XML file to be Zipped along with the old format and added the capacity for the new MS Office applications to reference those XML elements, the benefits of using XML would be much the same, if not identical, to the entirely new format, much to the benefit of users.

    One effect of the MSO-XML format is that it gradually pries old customers from their old versions of Office and forces them to upgrade to be compatible with the new format, regardless of the lack of benefit to them. I know who benefits from that.

  9. tlutz says:

    Specification is one side of the standards medal, implementation the other. How valuable is an open standard without proof by market, showing relevance within real world solution scenarios? Allthough OpenXML implementers are said to dig into 6.000 pages of documentation (which is only true, when you are writing a full clone of Microsoft Office) it seems to me that today´s hundreds of existing OpenXML solutions are quite easier and faster to get implemented in a higher quality than for ODF in comparision (where in fact to read quite more than the often said 600 pages, since they refer to several subcategorized standard documentations, adding the whole spec doc to several thousand pages…). My assumption is being supported by an experience from a recent conference in Vienna where even a representative of the EU agency IDABC criticized the overall quality of ODF implementations. This could be true for OpenXML implementations as well – but isn´t it remarkable, that currently the highest quality of ODF implementation is said to be done by the Microsoft Office 2007 OpenXML – ODF translator?

  10. hAl says:

    [quote]I don’t see how IBM could have a ‘responsibility’ for the comments.[/quote]

    It is absolutly fair to attribute the comments to IBM as they wrote them down and submitted them to the national bodies most likely to convince those national bodies to cast a vote of disapproval.

    Next move by IBM will undoubtedly be to focus on several issues that are not solved in the proposed Ecma and try to minimize the effect of  the revisions that were made to solve many many others. It will be interesting if the BRM agrees on revisions that solve 3400 issues how Rob will blow up the remaining 100 to mythical proportions (like he did with the compatibility tags).

  11. @Dave S – Yes, we did have some experience with Office, but from a nuts and bolts development point of view, we only wrote the old Excel binary format ourselves from scratch with Monarch V9, the most recent version, concurrently with implementing Open XML support.  

    Previously, we used very high level methods of reading and writing Excel, namely Jet and Excel COM Automation, which many of our customers were also quite able to do.  So to sum up, we had no <b>relevant</b> experience in implementing Office file formats, binary or XML, we had to learn everything during the Monarch V9 development cycle.

    As regards your point on the new format prying users from older users of Office, Microsoft make a free compatibility pack for users of older versions of Office, so they can read and write OpenXML at no extra cost.

    Gareth

  12. Andy says:

    My question is why ECMA keeps the comments resolution  in obscurity. I thought it was intended as an open standard?

  13. DaveS. says:

    @gareth, Those on more recent versions of Office are more likely to update than those who have not updated from older versions. The small businesses that still run Office97 were unlikely to -ever- buy a new version unless there comes to be a compatibility problem. Like there is with Office 2007 and MSO-XML.

    If many customers were able to cobble a solution using JET and COM, and MSO-XML is, it’s supposed, even easier, it sounds as if the market just got smaller.

  14. hAl says:

    @Andy

    Apperantly ISO rules dictate the BRM national bodies comments and Ecma responses not be published during the BRM phase leading up to the BRM meeting.

    Brian Jones on his blog already stated that Ecma would rather publish the information but is bound by the ISO rules on that.

  15. Fernando – As I’ve said before.  I am a Microsoft Partner as well, and sell migration and coexistence tools that allow people to move away from Notes/Domino if they choose.  Hardly IBM’s favorite business partner, but I do try to keep an open mind. Have you thought about trying that? – Ben

Skip to main content