The Standards Blog

A Peek Behind the Ecma OOXML Curtain

OpenDocument and OOXML

As the date for the February BRM (Ballot Resolution Meeting) on ISO/IEC JTC1 DIS 29500 (a/k/a Ecma 376, a/k/a Microsoft OOXML) approaches, more and more attention is being paid to how Ecma will propose the disposition of the comments submitted during the general voting period.  This level of heightened interest is legitimately urgent, due to both the great number of the comments that need to be resolved,  even after elimination of duplicates, as well because of the late date upon which the proposed resolutions will be made public (the deadline, if memory serves, is January 19, while the BRM will commence its deliberations on February 25 of next year).

The words are therefore flying fast and furious at the many blogs covering this question, and tempers are rising in the comments appended to those of bloggers that have a direct interest in the outcome.  A particularly contentious issue has been whether Ecma is trying to make it as easy as possible, or is trying to make it as difficult as possible while still scoring PR points, for interested parties to view proposed dispositions of comments, and whether it does, or does not, have the latitude under ISO rules to be more transparent.  The fairly opaque, and sometimes contradictory nature of those rules, has not made the debate any easier, and gives rise to the possibility of confusion, at best, and serious mistakes, at worst, as Pamela Jones pointed out at Groklaw this morning. 

The result is that there will be very little real data available to the general public until Ecma opens the curtains on January 19.  And the import of what little data does become available is usually the subject of instant disagreement.

With that as prelude, I've pasted in the text of a press release at the end of this blog entry that Ecma issued yesterday.  The release gives only a peek at some of the issues addressed in the new dispositions, giving varying degrees of detail on each area highlighted - but that's more than we've had to go on so far.  Here is my summary of the press release and its significance, when viewed in the context of other reliable, available information:

Progress status (numerical) - The number of comments posted at the password protected Ecma site is now 1,795, representing 51% of all of the comments originally submitted (the press release says "by the 87 voting countries," but I believe that the total number of countries that actually submitted comments, as compared to the number of countries eligible to vote, was lower).  The press release also says that Ecma is on track to complete its work by mid-January.

Progress status (difficulty) - According to Microsoft's Oliver Bell in a blog posting on the same press release, the previously posted dispositions largely covered the easy comments, and with this batch, the harder issues are now being addressed

Transparency - The press release states that "These proposed comment dispositions will be available to National Bodies via a website portal in order to solicit feedback from National Bodies to the Project Editor, in application of the ISO/IEC confidentiality principles."  As earlier noted, this touches on the very heated issue of whether access has been real and commendable, or difficult and exploited for PR purposes.  In this context, the use of the word "solicit" in the press release is worthy of note. 

Allowing for ISO 8601 Dates - One criticism of OOXML is that it does not utilize existing ISO/IEC standards wherever possible, as is expected of specifications offered for global approval.  The press release indicates that in at least the case of dates entered in spreadsheets, Ecma is recommending that DIS 29500 "will be updated to allow date values to be stored using the format defined by the ISO 8601 standard."  By using the word "allow" instead of words like "instead" (as elsewhere in the press release) I assume that this may indicate that two alternative methods will be allowed - use of the unique values originally included in OOXML or the ISO values, although we'll have to wait to see the full text of the recommended disposition to be sure.

Internationalized handling of weekdays and weekends - One issue with OOXML that many commentators had fun with in the past was a long-existing Office bug that did not allow certain dates to be associated with the actual day of the week to which they related.  I assume that this is the issue that is described in the press release as follows:  "ECMA-376 allowed for a week that begins on Sunday or Monday, but not a week that begins on any other day, such as Saturday."  The release says that a variety of possible resolutions, rather than a single recommendation, have been offered on this point.

Language tags - This is another case of OOXML utilizing unique tags, rather than available international standards ("ECMA-376 used a set of integer values to identify the language applied to regions of a document.")  Ecma is apparently recommending that DIS 29500 be amended to adopt the existing conventions.  In this case, it appears that this would be the only, rather than an alternative, method, as the press release uses the word "instead."

Page Borders - One of the most significant differences between ODF and OOXML is the level of detail that each mandates.  In the case of ODF, that level seeks to strike a balance between achieving interoperability between applications while allowing room for value-adding differentiation in other ways.  OOXML, in contrast, is heavily weighted towards ensuring that all features of legacy Office documents can be replicated with near-perfect fidelity in OOXML compliant applications, with concomitant restrictions on flexibility in implementation.  That difference was perhaps nowhere better demonstrated than by OOXML's specifying in detail all c. 200 borders available in Word.  It appears that rather than narrowing this list, Ecma will recommend that additional, custom borders could be used as well.

Usage of ISO standards for grammars - Ecma will recommend once again that certain unique spreadsheet and word processing elements included in Ecma 376 instead conform to an existing ISO standard (again, it appears that this would be a switch, rather than allowing unique and ISO grammars as alternatives).

How wide a peek? - Not very wide.  As noted in the press release, " These are obviously just a subset of the 1,795 proposed comment dispositions published to date."

Despite the meagerness of the sampling of recommendations described in the press release, it is possible to get an idea of the degree to which Ecma and Microsoft are willing to go in order to secure a final, favorable vote.  While I would invite those with a technical background to give their more informed opinions in comments to this blog entry, some of these changes strike me as being non-trivial at the technical level. 

There is another question, though, that IBM's Bob Sutor mentioned in a blog entry on the same Ecma press release yesterday:  If Microsoft commits to implement these changes in Office in an early service pack if DIS 29500 is approved, I assume that the work required of it would be non-trivial as well.  Hopefully, it will commit to do so, or the changes to DIS 29500 would be academic, given the central role of Office in the whole rationale for the standard to exist and be adopted in the first place.  Absent actual implementation by Microsoft, all of the efforts of all of those involved would be wasted.

In the months ahead, forces on both sides will be covering all information in great detail and, to put it mildly, each from their own perspective.  I'll be doing the same, striving for objectivity while acknowledging my own hope that ODF will become quite successful in the public and private marketplace.

And by the way:  if you haven't yet checked out my new eBook in progress on ODF and OOXML called War of the Words, check it out.


 

For further blog entries on ODF and OOXML, click here

sign up for a free subscription to Standards Today today!


* * * * * * * * * * * * * * * * * *



New set of proposed dispositions posted, including more positive changes to the Ecma Office Open XML formats – Dispositions now proposed for more than half of National Bodies’ comments
--------------------------------------------------------------------------------

The ISO/IEC DIS 29500 Project Editor is on track to produce a final document by mid-January 2008, containing proposed dispositions of all comments received during the ballot period. Today, Ecma TC45 is publishing proposed dispositions to a number of additional comments. Today’s posting brings the total of comments with proposed dispositions to 1,795, or 51% of the 3,522 total comments received across all 87 voting countries.

In response to the comments provided by National Standards Bodies around the world, Ecma is offering numerous changes to the Open XML standard that will ultimately improve the format.

Ecma, together with the Editor, will continue to review the remaining National Body comments in the weeks ahead, and provide proposed dispositions as quickly as possible leading up to the mid-January deadline. These proposed comment dispositions will be available to National Bodies via a website portal in order to solicit feedback from National Bodies to the Project Editor, in application of the ISO/IEC confidentiality principles.

Ecma looks forward to continued cooperation and collaboration with ISO, IEC, and ISO/IEC JTC 1.

This update proposes some significant changes that we believe address a number of the National Bodies’ concerns. We believe these changes strengthen the Open XML standard, better serving its users. Examples include but are not limited to:

1 Allowing for ISO-8601 Dates
ECMA-376, the original Open XML standard adopted by Ecma, assigned a unique numeric value to each date in a spreadsheet, in order to improve the speed of date calculations. Based on the comments received from some National Bodies on this issue, DIS 29500 will be updated to allow date values to be stored using the format defined by the ISO 8601 standard.

2 Internationalized handling of weekdays and weekends
ECMA-376 allowed for a week that begins on Sunday or Monday, but not a week that begins on any other day, such as Saturday. Ecma is proposing a comprehensive range of options for what is defined as the first day of the week, and what is defined as the weekend.

3 Language tags
ECMA-376 used a set of integer values to identify the language applied to regions of a document. Ecma is proposing that the language tags specified in the DIS should instead leverage an internationally recognized practice for representing languages, IETF BCP 47. IETF BCP 47 is a Best Current Practices document that incorporates use of the ISO 639 standard for languages, ISO 15924 for scripts, and ISO 3166 for regions. This proposal directly follows recommendations from National Bodies in several countries.

4 Page Borders
ECMA-376 included support for a variety of graphical elements that could be used as page borders. Several National Bodies noted that this closed list of graphical elements was not sufficiently diverse and global in its contents. Based on that feedback, Ecma is proposing to change the Open XML standard to allow for custom page borders. This will enable implementers to determine the best option for including borders relevant to their applications.

5 Usage of ISO standards for grammars
ECMA-376 used its own notation for defining the grammar for some of the more advanced functionality, such as spreadsheet formulas and word processing fields. Several National Bodies noted that the existing grammars in ECMA-376 are non-standard and were not fully described within the DIS. In response to this concern, Ecma proposes to revise the notation for spreadsheet formulas and fields to use an existing ISO standard. Formula notation will now use ISO/IEC 14977:1996 – Syntactic metalanguage – Extended BNF. This proposal improves the ability for implementers to test and validate conformance to the specification.

These are obviously just a subset of the 1,795 proposed comment dispositions published to date. Ecma will continue to work hard to review the remaining comments, and will work closely with the National Bodies to develop proposed dispositions for all of the comments received.

Comments

Permalink
Microsoft has admitted that maintenance of the OOXML standard will be Microsoft's sole responsibility under the auspices of ECMA.  So if approved by ISO OOXML will be a description of one vendors product that will be maintained by that vendor.  If OOXML fails to gain approval in ISO it will remain a single vendor's product maintained by that vendor.   So if nothing will be different whether the standard is accepted or not, why are we even discussing it as a standard?

Doug Webb
Canada

Doug,

Maintenance is (yet another) disputed issue - Check out both Rob Weir's and Brian Jones' blogs for some rather spirited back and forth on that issue.  

If OOXML gets approved, and regardless of whether Ecma maintains it, or a new formats working group gets formed with SC 34 to maintain both OOXML, and perhaps ODF as well (as has been discussed), or it ends up somewhere else entirely, it will nominally be a committee that makes the decisions about what future changes may be made.  However, if Microsoft does not commit to implement those changes (as Brian Jones indicated not long ago at his blog they might not), then it's hardly likely that the committee will decide to make any changes not approved by Microsoft.  What would be the purpose?

  -  Andy

I see your point, but I posit the contra-positive:

If Microsoft wants to take the approved spec back to the original definition of MSOffice as a 'maintenance' action, the maintenance committee could refuse to make those changes in the name of openness, equity to 3rd-party vendors that  are (presumably) trying to be compatible to the standardized OOXML, or out of a desire to *not* allow the standard to become patent/copyright/trademark encumbered.

Failure on MS' part to listen to the committee or to maintain currency with the standard would 'brand' them as being not complient with the OOXML standard "that they themselves promoted through ISO".  I imagine that should MS go down that road, their 'partners' and competitors (as well as the entire FOSS community) will publize that decision to all who will listen.  This publicity will leave no doubt as to whether MS intentionally broke standard or whether the 3rd-party vendors just 'did not get it right'.  This is one time where MS's history can come back to bite them if a past history of intentionally breaking standards to drive out competition can be demonstrated to purchasing decision-makers since such action violates every reason that standards-based systems are (were) selected i nthe first place.

The maintenance committee should be required (compelled?) to act to keep the spec open if it is ever approved by ISO - this means implementable by FOSS without a threat of MS lawsuits and it also means things like certification suites for OOXML compliance that can be run against Office 2007 documents to demonstrate OOXML compliance or lack thereof.  Without the agency of a committee not controlled by MS, none of the above checks or whistle-blowing can be accomplished any more than they are today (which is to say that intentional breakage of the standard by MS is VERY difficult to detect - let alone prove).

In summary, maintenance of OOXML by an open committee acting independently of MS (whether or not MS has influence in the approval of changes) can (at least in theory) act to curb any future MS attempts to coopt or ignore and ISO-approved standard.
  Finally, there are some situations where a change may need to be made without MS buy-in and where MS would need to either comply or lose certification to sell into various markets by abandoning the OOXML standard, and that is where 3rd-party implementors of OOXML run into a 'roadblock' where the spec may be ambiguous or may be legally encumbered or may refer to some non-open MS proprietary technology required as a pre-requisite for implementation (such as a hypothetical reliance on ActiveX).  In these situations, the committee should act to define the ambiguous (with or without MS approval) such that the spec remains open and implementable without MS proprietary technologies.

-- Ed

Permalink
Some of the problem with 'borders' is that a vendor (guess who !) might hold a commercial copyright on the border. It is the product of artistic endeavour, after all; and a number of them come bundled with the dominant office productivity suite.

So if I get a document which indicates 'border 47', and I wish to display the border, I might need to acquire a copyright licence. Maybe displaying is fair use, but how about forwarding, or reusing in other documents I write ?

Very interesting question.  Typically, the IPR policy of a standards organization requires that a working group member/employer must permit the standards organization to own the copyright in the spec and any derivative works, but in this case, the border is an output, not the spec, or a derivative work of the spec itself, I would assume.

That said, a word processor (for example) doesn't violate the copyright either, so long as it hasn't copied the code of the original work (in this case, Office), which wouldn't be the case.

So the actual infringer would presumably be the end user, which presumablly isn't going to be sued by the "certain vendor."  After all, that would be like saying that someone that uses Linux or OpenOffice should worry about whether they are violating the same vendor's patents...which, of course would be ridiculous, right?]

  -  Andy

Well, the end-user would probably be in the clear so long as they didn't distribute their document to anyone.

However, some end-users are governments and businesses large and small; not all the 'domestic' end-user who might get trapped between the corporate leviathans of IBM and Microsoft, but probably won't.

Who knows ?

Personally, I'm the 'engineering' type rather than the 'commercial legal' type. Set me a problem, I'll try to devise a solution. Like the Pied Piper of Hamelyn, the only way to get me to sue is if you agree a contract, I rid the town of rats, and the three thousand Guilders aren't forthcoming.

But I understand others are different.

Permalink
Isn't it so that Microsoft must implement the changes before OOXML can become an ISO standard? After all, until they implement the changes and convince Novell to also implement the changes, there will be no existing implementation of the spec. Doesn't ISO require at least two independent implementations of the spec before something can be made a standard?

Your information is incorrect. IETF and W3C have rules for implementability concerning  implementations IIRC. For the W3C, for example, they like each (major) feature to have been implemented to prove that implementation is possible, but does not require each individual implementation to be full. For OOXML, there are multiple implementations of ZIP, OPC, and certainly multiple systems implement the various *ML by import/export, apart from MS Office.
Rick Jelliffe

Permalink
I'm posting this response more visibly than usual, because it might be of general interest.

There is an understandable reason for the confusion over whether OOXMl should have been more broadly implemented in order to qualify for considerationr.  ODF, like most consortium standards that get adopted gy ISO/IEC JTC1, came in through what is called the "PAS Process" (for "Publicly Available Specification").  This process was created some years back to permit _established_ standards that were clearly useful and adopted to achieve a degree of official global recognition.  Consequently, ODF could not have been adopted if it had been in the same stage of development as OOXML was when it was submitted by Ecma, through a different process.

How is Ecma different?  It's a long story, but basically Ecma, a European standards group that had ambitions,  wangled a unique status with ISO/IEC quite a while back, becoming designated as the only "Class A Liaison" to the global bodies.  That status allows it to hand up specifications that have not yet been widely adopted. 

Which was, of course, one of the reasons that Microsoft selected Ecma for the job.

  -  Andy

Your information is incorrect. The criteria for PAS specifications to be considered can be found in Appendix M of the JTC1 directives. http://www.oreillynet.com/xml/blog/2007/07/where_are_the_various_document_1.html

There are various criteria. They are considered together, not with each being an absolute requirement. ECMA clearly meets the organization requirements (as far as ISO is concerned) and DIS29500 is credible on the documentation requirements (remembering that these requirements are entry criteria and defer detailed review to the subsequent year-long review and resolution process).

It is not at all clear that DIS29500 would not have been acceptable for processing in the PAS process, AFAICS.

Rick Jelliffe

Rick,

My consistent understanding, based on everything that I have heard from career-long professionals in the Big Is, ANSI and elsewhere has been that the PAS process was created to acknowledge industry standards that had already achieved wide uptake in the marketplace.  I think that while you could read Appendix Annex M to conclude that the door is open a bit wider, I think that the following excerpts (with some emphasis added) indicate that the acorns still aren't falling too far from that trunk (the full text is here; I've deleted much to make it easier to focus on the relevant points):

[I just tried to post these sections, and Geeklog keeps finding "spam" in them for some unknown reason.  I'm going to try to post them in a second reply after this one]

Admittedly, ODF wouldn't score well on one aspect of the above: availability of conformance testing.  But that's the only one that I think there is equivalence between ODF and OOXML.

Note that while some of these criteria may be closer to being met by February, the situation was far different at the time that OOXML was submitted to the Fast Track process.  Moreover, Microsoft now readily admits how much work remains to be done to make OOXML up to scratch.  Much of the language omitted talks about making sure that time is not wasted working with preliminary, non-high quality material that may waste the time fo participants. 

Over all, I think that it's pretty clear that the submission of OOXML certainly violated the history, spirit, and by my reading, also the letter of the rules.  I suspect that it is more likely that future changes will tighten things up than loosen them as a result.

  -  Andy

Andy: Aren't the Appendix M "shalls"  talk about the information that has to go in with the request?   This information must be provided, but there is no necessity for every star to align before a spec can be accepted.

Rick Jelliffe 

Rick,

Just read your latest O'Reilly post:  Rather odd to begin saying that you appreciate a rational exchange of ideas, and then take a rather different approach later in your piece.  Taking into account your statements there, it's not clear to me why you would be interested in my opinion on this point. 

In fact, there is a real confusion in the ISO rules as I read them.  This is a respectable viewpoint on the available information, and would better be dealt with on that basis than calling people clowns, or, as in the threads at this blog entry, simply stating "your information is inaccurate" instead of noting that at minimum things are not clear.

You might also note that, while I might have my own opinions about your objectivity, I haven't aired them in similar fashion at my blog.  And when I have disagreed with you, I have given my reasons in an objective and respectful fashion:  http://www.consortiuminfo.org/standardsblog/article.php?story=2007102801103588&query=jelliffe 

By the way - there are quite a few posts I've entered over the years that have either commended Microsoft for something they've done, or criticized IBM for an action that they've taken. 

Andy

I'm going to  delete more than I did originally and hope to loose whatever is sticking in Geeklog's craw.  Full text can be found here.

M7.2.2 Mandatory Elements

Of all the criteria, there are the following Clauses deemed to be essential for consideration of a PAS originator and a PAS for transposition <snip> below):

<snip>
  • Stability
  • Availability 
<snip>

The wording throughout the Clauses identified above is in terms of "shall" respond.  Hence, failure to respond to any of these Clauses will result in rejection of the application for recognition or of the submitted PAS.  All remaining criteria Clauses are, in effect, optional. 
A response is desired but not absolutely necessary.  The mandatory response Clauses have been identified by "(M)" after the clause heading.

<snip>

M.7.4.1.3 Testability (M)

The extent, use and availability of conformance/interoperability tests or means of implementation verification (e.g. availability of reference material for magnetic media) shall be described, as well as the provisions the specification has for testability.

The specification shall have had sufficient review over an extended time period to characterise it as being stable.

M.7.4.1.4 Stability (M):

    a) How long has the specification existed, unchanged, since some form of verification (e.g. prototype testing, paper analysis, full interoperability tests) has been achieved?
    b) To what extent and for how long have products been implemented using the specification?
    c) What mechanisms are in place to track versions, fixes, and addenda?

M.7.4.1.5 Availability (M):

<snip>

    b) How long has the specification been available?

<snip>

M.7.4.2.3  Market Acceptance:

    a) How widespread is the market acceptance today? Anticipated?
    b) What evidence is there of market acceptance in the literature?

M.7.4.2.4 Credibility:

    a) What is the extent and use of conformance tests or means of implementation verification?
    b) What provisions does the specification have for testability?

M7.4.3 Alignment

The specification should be aligned with existing JTC 1 standards or ongoing work and thus complement existing standards, architectures and style guides.  Any conflicts with existing standards, architectures and style guides should be made clear and justified.

M.7.4.3.1 Relationship to Existing Standards:

    a) What international standards are closely related to the specification and how?
    b) To what international standards is the proposed specification a natural extension?

<snip>

M.7.4.3.3  Substitution and Replacement:


    a) What needs exist, if any, to replace an existing international standard? Rationale?

<snip>

   c) What portions, if any, of the specification do not belong in an international standard (e.g. too implementation-specific)?