[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]