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?


Daniel Carrera wrote:

> Hello,
> 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?
I like Robert's analysis of where we are now, that is we should not make 
changes that render existing documents in the ODF 1.0 "family" incompatible.

I have tried several responses but keep getting stuck on what is meant 
by "valid." If they are valid ODF 1.0 documents they will remain so. 
And, I don't know of anything that would prohibit ODF >= 2.0 from 
specifying how to read an earlier version, if some non-backwards 
compatible change was made.

And it is difficult to discuss in the abstract since the landscape of 
office applications has evolved from incompatible stand alone formats 
(some members of the committee will remember the conversion programs 
that offered to and from conversions for a variety of formats) for 
personal computers to emerging network service architectures. And it 
doesn't feel like it has been that long in between. ;-)

I would suggest that we always "try" to maintain backwards compatibility 
for ODF >= 2.0 but leave ourselves the ability to deal with requirements 
and architectures that we can't presently imagine.

Hope you are having a great day!


> Robert Weir wrote a poposal on the OD-users list which I copy below.
> <robert>
> One way of looking it is like this:
> 1) Versions of ODF that are part of the ODF 1.0 "family" must remain 
> compatible with each other.  This means any document valid/conformant 
> with one revision of the specification is also valid/conformant with 
> the others.  This would limit our changes to errata and new features 
> which can be added in a backwards-compatible way.  Format revisions of 
> the same "family" would share the same value of the office:version 
> attribute.
> 2) At certain points in the evolution of ODF, we may wish to make 
> larger changes, a big leap forward.  This would result in us issuing a 
> major specification update, e.g., ODF 2.0, and incrementing the 
> office:version attribute.  Backwards compatibility would not be 
> guaranteed.
> So, at some stages the goal is simply to make a "good enough" fix, for 
> now, to address an issue without breaking compatibility.  And then at 
> periodic points, perhaps every two years or so, we can make more 
> substantial changes.
> It is a tricky balancing act and there is more than one way of looking 
> at this.
> </robert>
> Best,
> Daniel.

Patrick Durusau
Chair, V1 - Text Processing: Office and Publishing Systems Interface
Co-Editor, ISO 13250, Topic Maps -- Reference Model
Member, Text Encoding Initiative Board of Directors, 2003-2005

Topic Maps: Human, not artificial, intelligence at work! 

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