OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [office] Backwards compatibility?

"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?


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]