Archives


Atom Feed

Associated Blogs
 
Edge City
 
Numbering Peano
 
Orcmid's Live Hideout
 
Praxis101
 
Prof. von Clueless in the Blunder Dome

Recent Items
 
Golden Geek: Wandering into Computing
 
Don't Call Me a Coder!
 
Internet Identity Workshop: May 12-14, 2008
 
Design for Interoperability: Is It Like the Weathe...
 
OOXML+ODF: ISO Steps In
 
Unburdening Overwhelm: Covey and Peace of Conscien...
 
Dreaming in Code: The Long Tail to My Little Ecco
 
The Unbearable Overwhelm of Technical Debt
 
Public Availability of Standards
 
On the Giving Away

ODF 1.2, Hijacked by OO.o?

This is not a post that I wanted to write.  The situation has been nagging at me and I need to lay it to out to give myself some rest.  My nightmare is that the worst possible thing is happening to completely undermine the prospect for successful open document-format standards: the building of a favored implementation prior to the public availability of even a public draft specification.  No, I don't mean Microsoft Office, and I don't mean OOXML DIS 29500 final (or IS 29500).

1. Flash Back

Following the agreement on changes to ISO/IEC DIS 29500 (OOXML) at the Geneva Ballot Resolution Meeting, the ISO/IEC JTC1 SC34, meeting in Oslo on April 5-9, 2008, initiated a maintenance process for IS 29500 (the official form of the revised DIS 29500 documents).  To support its moving forward in that and related work, SC34 Resolution 8 from the meeting requests copies of DIS 29500 final, the revised material reflecting the BRM agreements:

"SC 34 requests the ITTF and the SC34 secretariat to distribute the already received final text of DIS 29500 to the SC 34 members in accordance with JTC 1 directives section 13.12 as soon as possible, but not later than May 1st 2008. Access to this document is important for the success of various ISO/IEC 29500 maintenance activities."

The following elements strike me as important:

• On April 9, 2008, the attending member of SC34 seemed to have information that the modifications to make DIS 29500 final had been made and DIS 29500 final was in the hands of ITTF and perhaps the SC34 secretariat.  Based on this, it is reasonable to surmise that the document is out of the hands of ECMA and any Microsoft contribution to the document-revision effort.
    
• It is now May 17, 2008, and there are no reports of DIS 29500 final being distributed to SC34 members or otherwise being made available. 
    
• If you go to the ISO catalog entry for IS 29500 (click "Standards under development"), you'll see that the new organization into four parts is listed but no files are available for download or purchase.  The project stage (40.99) reflects that DIS 29500 is approved.  There are other stages to have it appear in published form.

People are wondering when a final version will be available.  On May 16, Yoon-Kit Yong (no fan of OOXML) commented on a blog post that the SC34 Secretariat claims to have DIS 29500final and (as quoted by Yong):

"I was asked by ITTF not to distribute it to the SC 34 members since the availability of the slightly different version from the actually published version would be confusing.  

"ITTF informed me that the proof will be available in a few weeks and I am intending to post the proof (after confirmation by the project editor) on the SC 34 website as soon as it becomes available."

It would appear that the ITTF is marching ahead to produce the published IS 29500.  It may be a few weeks before someone manages to post the proof documents and start delighting in whatever defects are apparent.  Meanwhile, this modus operandi is providing lots of room for cynical speculation and apprehension.

2. Flash Forward

On May 4, Rob Weir commanded "Release the OOXML final DIS now!"  Waiving the JTC1 Directives in the air, Weir points out that the missing DIS 29500final is in violation of the procedures.  I don't know what is served by instructing the SC34 Secretariat in this manner.  I would think that National Body members of SC34 are the ones to act and to raise concerns about procedural issues with the SC34 Secretariat and IITF.

I'm also disappointed that the specification, with all the interest that has been generated, is not available, especially to those who would want to ensure that the BRM-agreed changes are properly reflected and that nothing untoward has occurred as well.  Being an outside observe of this process, I simply presume a proof of IS 29500 (one can't say draft in this context) is important for accomplishing that. 

Weir speculates three difficulties that this delay reflects:

1. The need of DIS 29500final as the basis for appeals to the process inside the two-month appeal period.
     
   I'm not sure why DIS 29500final is needed for that; I also trust that defects in reflecting the BRM agreements will be identified and resolved in some responsible editorial process.
     
   I would think that any National Body that is considering an appeal is perfectly capable of working this out with JTC1 and ITTF as well.
     
2. Use as evidence in a lawsuit in the UK (and in conjunction with other actions, I suspect, where NBs are charged with inappropriate conduct in their voting).
    
   Something tells me the parties and courts involved can deal with that issue themselves.  Weir's legal theory about the materiality of the approved document cuts both ways and I'm sure the parties will haggle it out in coming before a court or other body.  Meanwhile we can enjoy watching how matters of standing and jurisdiction (and their counterparts in those venues) are thrashed out.
     
3. The advantage of at least two months that this gives Microsoft to bring its products into conformance with IS 29500. 
     
   This seems silly alongside the often-professed claim that no one else can implement OOXML anyhow. 
     
   There are two mitigating situations.  First, the BRM-approved changes (as instructions to the editor) are certainly known to the parties who may be worrying about this.  Weir knows what the directions to the editor are.  Even I know what they are.  Secondly, a large part of ECMA-376 remains usable, even with the changes of status of many features to transitional.  In fact, according to some experiments by Alex Brown reported on April 17 (and using IS 29500 schemas that he was able to obtain), the breaking changes for current implementations of ECMA-376 are quite few (and those could have been avoided if the old forms had been made transitional). 
     
   In short, I don't think Microsoft needs a head start at all, even though patches to the current Office 2007, Office 2008, and the Compatibility Pack would foster a world where the breaking changes are slowly filtered out of new documents and those existing documents that happen to be opened in updated software.  I'm speculating that further changes to increase desirable use (i.e., more strict conformance and less transitional conformance) of IS 29500 features by Microsoft can then come with future versions of Microsoft Office.  Future Office System version will likely accept transitional forms and optionally-produce transitional forms as part of the usual up-/down-level interoperability now that there is a legacy of non-strict OOXML (ECMA-376) documents and applications that accept them.

Of course, I am not a lawyer, not even in the UK or other international jurisdiction.  And I have no knowledge of Microsoft's approach to aligning with IS 29500.

3. Checking the Parallel Reality

I follow the GullFOSS blog of the OpenOffice.org engineering team at Sun Microsystems.  The periodic status reports, such as this one from March 2008,  are intriguing to me for what they intimate about support for OOXML and, more than that, new functionality expected as part of ODF 1.2. 

I keep an eye cocked for mentions of OpenFormula and other new features of ODF 1.2.  It is interesting to see the OO.o team busily building various bits of ODF 1.2 functionality for future release in OpenOffice.org. 

I haven't been digging into the details beyond the occasional look at the ODF Technical Committee's public-document collection for ODF and for OpenFormula on the OASIS site.  I'm not on the TC and not part of an ODF development team.  I avoid beta releases in general and I don't look that closely at the working drafts produced internal to the TC.  I'd just been keeping my eye out for some sense of the work being close enough where it would be good to anticipate the public review (if required) and publication of ODF 1.2.

Although I should have been prepared for it, I was still surprised that OpenOffice.org 3.0 beta was announced with  ODF 1.2 support.  (Support for OOXML is also an announced feature, so there is apparently enough known about ECMA-376 and IS 29500 that the OO.o team is not dissuaded.)

There are two aspects to this that concern me.  (Actually, they disturbed me.  I have since calmed down.)

1. Is ODF 1.2 Soup Yet?
    
   I don't think so.  To check on this, I went nosing for the latest documents last night.  In terms of having committee drafts to report out of the ODF TC, I don't think they are ready.  I'm not close enough to assess how far from completed committee drafts they are.  Yet, according to the minutes of a 2008-02-11 TC phone meeting, we could be 5 months away from an OASIS-approved ODF 1.2 document, even if the committee approved completed drafts tomorrow.  It is conceivable that OO.o 3.0 will go to production release before ODF 1.2 is published as an OASIS Standard.
     
   Now, it is completely possible that the technical details, the agreed schema, and other agreements that determine the feature set enough to be implemented have been established by the TC, with those aspects pretty-much locked down for ODF 1.2.  Then what's left is documentation and exposition.  That's possible, but it is difficult to ferret that out without having been part of the TC.  It is unclear how to find the approved technical proposals for ODF 1.2 without being a TC member.  [update 2008-05-19T14:40Z Clarity Arrives. Thanks to Rob Weir for pointing out that there is a public page on the TC Wiki that provides the complete history of approved and under-review proposals for ODF 1.2.]
     
   This is the kind of head-start that participation on a technical committee provides.  There are risks of being left behind when there are last-minute specification changes and there are further risks of deviant implementations of various features just because of misunderstanding of the incomplete information.  Still, this isn't that unusual.  [update 2008-05-19T14:40Z Not a terrible head-start. I agree with Rob Weir that it is desirable for this sort of proving-out and preparation is valuable, and my concerns about this being exclusive to the TC are dispelled.]
   
    
2. Are We Making ODF 1.2 Whatever OO.o Does?
     
   This concerns me more.  There are a lot of folk out there exulting that OO.o 3.0 beta supports ODF 1.2.  Since I don't think those happy commentators have any way of knowing what ODF 1.2 is, I am very concerned that we are sliding down the usual slope toward taking an implementation as "the standard."  I fear a "Here comes the new boss, just like the old boss" situation.  [update 2008-05-19T15:24Z More murky. I think this remains an appropriate concern, although more murky and independent of what the OpenDocument TC does.  It is more about how people not engaged with the standards respond to the asserted standardness of products, such as the OO.o 3.0 beta and later releases.  This worry is also applicable to OOXML and that concern has been expressed in many settings.  There is a social behavior and there is also contributory vendor behavior.  I'm not sure how far a standards-development body can go to minimize this prospect, but experience shows that care at this stage can matter in the handling of conformance, versioning, and the way extensions outside of the standard are tolerated.  Murk, murk, murk.]
     
   If folk in the ODF-supporting community wanted to get together and confirm that their implementations could be used interoperably, how would the inevitable misunderstandings and potholes be adjudicated with no specification to appeal to and also to clarify?  This is worrisome, unless OpenOffice.org is allowed to define the default reality.
     
   There's one more pitfall wired into the ODF specification that makes it more likely to have an implementation dictate what ODF is.  I didn't catch this out until recently, although it was right before my nose all along. 
      
   ODF 1.0 (and its sequels) specify the file-name extensions that should be used on ODF-conforming documents.  This means that all implementations of ODF text documents are expected to use .odt as the filename extension, for example.  The tendency is to have no identification of the relevant software product separate from the fact that some form of ODF conformance is intended.  This is so even though an ODF-conforming package file has an easily-detected MIME-type entry that distinguishes the format being honored regardless of what the package file is named.
           
   I would think that reusing the filename extensions is going to drive implementations of ODF to want to shadow the feature set of a dominant product to ensure customer-satisfying interoperability.  At this point, that dominant product appears to be OpenOffice.org.  I am not sure what would happen if a player broke the mold and started using distinct extensions while otherwise using the formats properly.  Using the extensions is a should, not a must, but that may be irrelevant in reality and in terms of what user expectations are.

4. Zen Karma Penance

There's a sort of Zen principle that says when we are angry or upset with others, it is something about us that we are seeing in the mirror.  Sometime our reactions are exactly the behavior we are accusing others of.  (Don't take this as an absolute, and I won't defend this against outrageous examples.)

The value of the principle is having us look at what there is about ourselves that offends us when seen or suspected in others.

So how am I doing that, I ask myself?  Nothing goes "clunk." 

Maybe it's reacting without finding available facts?  Or, complaining in public rather than interacting with those who are inside the situation and know the score? (That pinches a bit.) Something else?   [update 2008-05-19T14:40Z All of Those.  Yup, if I'd looked more closely at the wiki and/or asked someone on the TC, I could have tempered this post or not even written it.]

It may be easier for someone else to spot than I can do for myself.  I'm open to suggestions as to what it is.  I do know I need to look around for more public OpenDocument TC documents to see what additional information there is on ODF 1.2 content details.

Meanwhile, since I have begun delving into the ODF 1.2 drafts that I've found so far, I'm performing some public-service penance by reviewing and commenting.  When IS 29500 is available, I'll do the same. 

One advantage of the OpenDocument TC operation is that the comment and discussion lists seem to be more open (and bidirectional) than has been the case so far with ECMA TC45 and ISO/IEC JTC1 SC34. [update 2008-05-19T14:40Z And the Wiki Too: The use of a TC-editable and public-readable Wiki is valuable and much easier for finding coordinated material than scouring the comment list.]

 
Comments:

 
Dennis, it is not all that hard to find out the status of ODF 1.2. The TC uses a wiki to track these things. This is pointed to from almost every meeting agenda, and the agenda is posted to the public list. But in case you've missed this, you can see the list of ODF 1.2 changes here. So the key premise of yor argument -- that no one outside of the TC knows what ODF 1.2 contains until the standard is finished -- is false.

As for starting to see draft implementations of ODF 1.2, that's a good thing, right? Implementation experience of a draft standard is valuable input into the process. In fact, OASIS rules require that we have three successful uses of a draft by OASIS memberorganizations before we can put it out for an OASIS Standard vote.

The file extensions question, I wonder, has the .html/.htm convention for HTML lead to any problems? Or .cpp for C++ files? Remember, we still deal with many pre-web, pre-mime systems that distinguish file types of file extensions. So having uniform extensions, in addition to a MIME type is a useful optimization.

In many cases, such as downloading an ODF file from a web server that has not been configured to serve up ODF files with the proper MIME type, having the ODF file extensions are the only thing that will give the right clue to the web browser on what application to launch.

# posted by  Rob: 18 May, 2008 19:25

 

 
Dennis, I really appreciate your openness in discussing the issues.

For me the issues about an implementation taking the place of a specified standard are the most worrisome. It's pretty hard to make reproducible measurements without some kind of ruler. But, as you point out, maybe in practice it won't matter so much. The good news is that this is a nice empirical question. Time will tell.

Finally, Rob, I really think that depending on names as reliable and accurate description of content format is a problem more than a solution. Don't get me wrong, I do it all the time myself when I go out of my way to label my text files with ".txt" extensions. I'd really prefer to query the document itself about it's format (and its provenance). One can always dream.

-Bill

# posted by  Bill Anderson: 19 May, 2008 07:57

 

 
Rob, thanks. The Wiki page is exactly what I needed to find. I agree that this erases my key premise and I have adjusted the post (and will make a follow-up).

Yes, on provisional and exploratory implementations, with the usual caveats and concerns about releasing these into the wild before the specification is fully-baked at some level.

I think the .htm and .html situation is murkier, and for those of us who don't build web servers or browsers, mainly resolved by MIME type text/html in HTTP response headers. This very blog page, with URL ending in .asp, is actually served up as tet/html, for example (long story). Also, the magic numbers and MIME types for ODF packages should be sufficient. I need to try that out with some ODF-supporting applications.

# posted by  orcmid: 19 May, 2008 08:18

 

Post a Comment