Re: [office] Backwards compatibility?

[robert_weir@us.ibm.com]

"David A. Wheeler" <dwheeler@dwheeler.com>
wrote on 03/15/2006 02:10:46 PM:

> 
> >> Daniel Carrera wrote:
> >>> The recent discussion about style name uniqueness raises
a more 
> >>> general question: How much do we care about backwards
compatibility? 
> >>> Are we willing to change the format in a way that makes
some 
> >>> existing files invalid? Or do we want to guarantee that
once a file 
> >>> is valid it will always be valid?
> 
> Perfect guarantees are hard to provide, but I think we should preserve
> backwards compatibility unless there is a very good reason to do otherwise.
> 
> XML formats, like OpenDocument, are usually pretty easy to expand
on.  
> Just add a new attribute or tag; that won't invalidate the documents
> that don't use it.  If something wasn't specified clearly enough,
then 
> you can often appeal to existing practice and document it.  So
backwards 
> compatibility should often be fairly easy to achieve.
> 
> Now if there's a CRITICAL reason to make a big change, it's still
> possible.  Through namespaces, it can even be mostly invisible
to 
> users.  Given all the review, and the number of players, I don't
expect 
> that to happen often, though.
> 
> Currently, I expect a lot more work to going into clarifying what's
> underspecified (like formulas or angle units of measure), or adding
> whole new capabilities that don't interfere with existing documents
> (like most metadata).  The basics of office documentation are
really 
> stable; nothing really interesting or compelling has happened 
> TECHNICALLY for 15 years at least.

Two general types of ways to evolve a schema -- widening
the contract or narrowing the contract.  Widening can break backwards
compatibility.  Narrowing can break forward compatibility.

If you add a new optional attribute, in an existing
name space, then you are widening, i.e., you are allowing something in
the markup that was not allowed before.  An older conformant implementation
would be within its rights to reject that document since it does not match
the schema it expected.

If you add the new attribute in a new namespace, then
we are fine, according to section 1.5 of the ODF spec. 

If we do a narrowing constraint, such as requiring
uniqueness where none was required before, then we may have problems with
existing documents.

I don't want to be an absolutist in this area.  We
all have things we want to add to ODF, short term and long term.  Incompatible
changes will come at some point.  But I would like to see the TC have
a consensus understanding, hopefully codified in a working document, on
how it will deal with evolution and versioning.   What are the best
practices for ensuring that we don't confuse implementors and users with
unexpected incompatible changes?  How do we set the right expectations
on when and how such incompatible changes will happen?


-Rob