RE: [office] Evolving ODF, Interop and Multiple Implementations

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

I think this is an interesting notion.

Thoughts:

 1. Intentions to implement are difficult to take into account, since these are voluntary standards and there should be care about that.  However, if there is some community agreement where an extension has been implemented successfully by more than one producer (i.e., there is already demonstrated interoperability of independent implementations), that would certainly carry some weight.  Of course, it is often the case that working such an agreed feature into the specification will lead to adjustments as part of implementation-independence.

 2. Another way to work this is the way that features progress in other venues, such as the IETF.  There is early specification of a feature having mutual interest, but it stays in draft until there are implementations.  It doesn't even get to the equivalent of a Committee Spec until interoperable use is confirmed and the rough edges adjusted, unsupported aspects removed, etc.  And then it rolls into a Standard.  This raises some problems around changes over time and the management of identifiers and namespaces for XML-based formats though.

 3. It appears that another way to work on the lines of (2) would be to have provisional features, with provisional identifiers and namespaces, that are not confused with anything in the standard and occur as extensions in implementations.  There is a way to also reserve what would be the adopted identifiers and namespaces, so that supporting consumers could accept either designations, but producers would only use the provisional identifiers and namespaces.  If the feature doesn't make it into a standard in interoperable form with the extension, the reserved designations are never adopted.  (The extension remains usable as an extension and there is never any confusion with an incompatible variant that makes it into the standard, since that would not conflict with the reserved ones that were not adopted.)

4. I am proposing something along the lines of (3) for changes to protection keys and also for changes in the key derivation in ODF 1.3.  The proposals establish reserved identifiers that would go into a Committee Draft but would be abandoned if a subsequent Committee Draft or Committee Specification ended up with an incompatible definition -- requiring other identifiers.  What's missing is any introduction of an OASIS namespace entirely for provisional use in extensions only.  I presumed that community-agreement on extension identifiers for the provisional feature could happen outside of the ODF TC.  But perhaps there is a way to also issue provision-for-extensions-only namespaces and identifiers.  The proposals work either way, so long as the reserved designations are (1) never adopted or (2) never used for an incompatible provision. 

 - Dennis


-----Original Message-----
From: office@lists.oasis-open.org [mailto:office@lists.oasis-open.org] On Behalf Of robert_weir@us.ibm.com
Sent: Monday, October 22, 2012 08:41
To: office@lists.oasis-open.org
Subject: [office] Evolving ODF, Interop and Multiple Implementations

I want to toss in this idea, for a possible criterion for how we evolve ODF into ODF 1.3.   

As we know ODF has powerful extensibility mechanisms via foreign attributes and elements, in application-defined namespaces.  The ODF 1.2 specification has extended conformance clauses to handle these cases.  So any implementation should currently be able to extend ODF and still claim conformance, so long as they have the basics (the non-extended parts) in conformance. 

This leads to the question:  As we evolve ODF, when should we decide to add new capabilities to the specification versus leaving them as implementation-defined extensions? 

I'd like to suggest that we do this based on the existence of *multiple implementations* of the new capability, or at least of committed plans of multiple implementers to implement the new capability. 

In other words, I'd like to discourage adding capabilities to ODF 1.3 unless it promotes interoperability.  If only a single implementation will support a proposed feature, then existing extensibility mechanisms should be used. 

Thoughts? 

-Rob