Conformance and Certification: The ODF Standard and Microsoft's Office Open XML Specification

Excellent posts are appearing over the past 10 days on interesting and apparent contradictions in the Microsoft Office Open XML specification, their related patent promise, and the resulting effects on the ISO standards process.   (All are listed at the end of this post.)

Indeed, ECMA perhaps should be a little embarrassed that they passed the specification in ballot if such contradictions exist, but at 4000+ pages, one perhaps can be a little forgiving.  (Hopefully they evolve their process to adjust in the future for such outrageously large submissions from their members.)

I've pointed out elsewhere:

• Standards exist to enable and encourage multiple implementations, regardless of the forum in which they are created.  They benefit the consumer.  A vendor specification, regardless of whether it has gone through a formal standards process exists to encourage multiple add-ons to a single implementation, i.e. it benefits the vendor.
• Microsoft chose the most expensive worst possible way to deal with the ODF standard, and they will ultimately lose the battle because the standard with the most implementations historically wins in the marketplace. 

That said, huge concern and uncertainty exists for what's going to happen going forward with respect to ISO and Microsoft's ECMA specification, and the future of ODF. 

I'm going to take a slightly different view here.  ECMA has already approved the specification.  One can imagine that the Microsoft marketing and standards engines are in full gear, and Microsoft execs, Office spokespeople, and field account execs are faithfully espousing:

• "Microsoft Office 2007 is standards compliant.  ECMA International is a recognized international standards organization, with participation from IBM, HP, Intel, Adobe, and dozens of other companies."  [Subtext: It must be a good standard for all our partners and competitors to have passed it in a fair-minded international standards process.]
• "Indeed, ECMA International has submitted the standard to ISO for fast track approval as an international standard, and the process will complete in 2007."  [Subtext:  It's so good, that they have recommended it for FAST track at the world's premier standards body.]
  

I would be surprised if Microsoft's Massachusetts team isn't already lobbying to have the new "standard" included in the ITD reference architecture alongside ODF.   Regardless of the merit of ISO accepting the document, however, buyers will be staring the nasty rhetorical beast in the teeth.  So what is a procuring organization to do?

Historically at the federal level in the United States, the National Institute of Standards and Technology (NIST) developed Federal Information Procurement Standards (FIPS). These FIPS contained the description of a standard (perhaps developed elsewhere like ANSI or ISO), and what it would take to use that standard in federal government procurements.  The FIPS would also outline any certification testing requirements that NIST felt were warranted, and indeed for U.S. government procurement NIST [wisely] continued to put its money where its mouth was and developed the test suites that were used.  This was back in the days when the head of NIST was a civil servant instead of a presidential appointment, and the organization thereafter devolved into politics and destroyed many of these "boring" testing programs.

But it was an excellent example of a working model to solve concerns here. 

Standards organizations are best designed to develop specifications into consensus oriented standards.  They serve implementors directly.  They serve the marketplace indirectly by laying the specification foundation for producing lots of implementations. 

It is up to the parts of the marketplace that [economically] care about true conformance to define the certification process that fits the situation.   It could be the procuring side of the marketplace (as with the historical NIST programs), or the implementing side of the marketplace (as with the X/Open-Opengroup certification programs). 

So supporters of ODF (and by this I mean implementors) need to choose the organization that best represents their needs, and deliver a proper certification process.

The ODF Alliance is a likely candidate for at least defining the certification criteria and being the keeper of the certification "brand" so to speak.  Its recognized purpose is to promote the use of the standard, and document its use to support procurement.  Perhaps the Opengroup has a role to play because it has the pre-built infrastructure to support testing and certification on behalf of the ODF Alliance. 

OASIS is excused -- it's the standards development organization.  At best, it defines the conformance criteria for its specification.  Remember, the marketplace needs to take appropriate economic responsibility for certifying that conformance. 

As long as the certifying organization doesn't lose sight of the goal, i.e. as long as it doesn't think certification is a Big Revenue Generator, then the numerous products and online services supporting ODF will be able to quickly demonstrate conformance and certify.  This gives procurement agents their first tool: a recognized brand to specify in their requests for proposals (RFP).  The certification brand becomes an easy short-hand for "that document format standards thing with many implementations."

Microsoft can easily replicate this, and indeed will need so to do to even be perceived to be on a par with the ODF certification world.  It won't matter that there may be truck-sized defects in their rapidly created certification process.  It likewise won't matter if they actually fail to maintain their ability to certify. [They cut the specification into ECMA before they finished the product.  Trust me -- it will have drifted.]  It won't even matter if their certification process is superior!  There will only ever be one implementation that can certify.  It will also be difficult to create the same perceived arms length distance from their certification process that ECMA gave them from the specification.   And it still won't matter. 

Bidders can certainly offer Microsoft Office 2007 plus its conversion tools to meet the ODF certification requirements of the RFP.  But it will have to stand against all the other native solutions for price, performance, and ease of use. 

Likewise, Microsoft or their partners could lobby to get the MOOX "standard" and its needed certification process onto the RFP, BUT the procurement agents now have a second tool.  They have the ability to require that any document format standard on the RFP must support a certification process with at least N certified implementations available at the time of the RFP. 

That will become the industry norm to meet in this space. 

"Standards" with only one implementation aren't.  The buying side of the marketplace has always recognized this and chosen the standard with multiple implementations over the specification with only a single implementation.  The ODF world has the ability to demonstrate this message in a way that meets the needs of customers, and the demonstration through a branded certification is much more powerful than unaligned vendor rhetoric. 

Go get 'em.

Links:

• Andy Updegrove's excellent analysis of the contradictions and their effect on the ISO standards process. 
• Sam Hiser analysis and discussion on the contradictions in the Microsoft patent license. 
• Bob Sutor covers the technical specification contradictions with links to the relevant places.
• Groklaw has indepth coverage to set the context of Microsoft's promises.  It is tempting to take this as simple Microsoft bashing, but the deeper problem this post emphasizes is the problems a vendor faces in the marketplace once trust has been broken.  There are good links throughout. 
• Rob Weir really kicked it all off when he start going deep on the technical contradictions in the Microsoft specification. 

Comments

[W^L+]

I appreciate your unique input. Hopefully, someone will listen.