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] Concerning backwards compatibility in odf 1.2


On 29/03/07, robert_weir@us.ibm.com <robert_weir@us.ibm.com> wrote:
>
> Hi Lars,
>
> You right to draw a distinction between application compatibility versus
> document compatibility.
>
> The four basic questions I have in mind are:
>
>    1. Are documents that are conformant according to the ODF 1.0 or ODF 1.1
> specifications also conformant according to the ODF 1.2 specification?  If
> not, what are the exceptions?

That (for forwards compatibility) I can rely on the 'lars' updater software
to get there? Not yours, but someone with motivation enough to get me
from version n to n+1.
<goal>The files on disk can live for 5 years</goal>




>
> I'd like to hope that the list of exceptions is small.  Whenever possible we
> should try to introduce compatible changes.

But only as a 'nice to have'?

>
>    2. Are documents that are conformant to the ODF 1.2 specification also
> conformant to the ODF 1.0 or ODF 1.1 specifications?   If not, what are the
> exceptions?

None. you want to go back in time?
Your problem.
Don't expect OSS to support you?
A bit crude, but I don't see us (or anyone with sense) supporting the future?



>
> This will be less likely to be true.  Whenever we add a new mandatory
> element or attribute, or expand the allowed range of attribute values, we
> are losing this level of compatibility.

The gain is that the new item is a step forward?


>
>    3. Can an application that is written to the ODF 1.2 specification able
> to also load ODF 1.0 and ODF 1.1 documents?  If not, what are the
> exceptions?

The hard parts.
Error: Some parts of this document are not compatible with version (n-1)
please update your application.

That sounds quite reasonable to me?


>
> In other words, if someone sits down next year with the ODF 1.2 standard,
> and writes an application using just the info in that specification, will
> their code be able to also read legacy ODF documents?  I'd like to be able
> to preserve this.  So we should not remove anything from the ODF
> specification.
Only with 'pre-processing'?
  Please don't constrain ODF to handling n year old instances?
I'm sure company X will have motivation to provide an 'update' app/filter.
Hopefully they will share it and ease the pain of others.
Don't hold the standard back for laggards :-)


 We can deprecate and provide alternatives.  But we probably
> should try to keep the ODF specification in a comprehensive state, so it has
> all information needed to implement the current, and previous versions of
> ODF.

I'd like to restrict that to version (current) - 1?




>
>    4. Can an application that is written to the ODF 1.0 specification also
> load ODF 1.2 documents?  If not, what are the exceptions?
I don't care. Go update your application.
Please feel free to blow up on 'future' data.



>
> This is a question about degrading gracefully.  This will not work in the
> general case.
The case should be (IMHO). Blow up, with a gentle error message,
"I've met something I don't understand.
The file is from version x.y, I don't process that"

IMVHO, that is 'degrading gracefully'.



> So I'd emphasize the documentation aspect of this.  We can break backwards
> compatibility where necessary, but we should carefully document each
> instances where we do this, as an aid to implementors.

Or restrict it?

Just my 2 penneth.... sorry, 2 euro's.

regards

-- 
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk


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