OASIS Open Document Format for Office Applications (OpenDocument) TC

 View Only
  • 1.  Concerning backwards compatibility in odf 1.2

    Posted 03-28-2007 08:57
    Dear TC,
    
    We concluded in our last conference call, that many of the problems that 
    we are seeing with the debate about lists and numbered paragraphs 
    circles around the various notions about the guarantees that we are 
    willing to make concerning the behavior of applications that were 
    implemented with ODF 1.0/1.1 in mind when they are to open an ODF 1.2 
    document.
    
    There has also been the question of ODF 1.1 in ODF 1.2 applications, 
    which I do not view as a problem at all. An ODF 1.2 Application can tell 
    an ODF 1.1 document from an ODF 1.2 document by looking at the (now 
    required) version-attribute in the office:document element. The 
    application can then act accordingly. In cases, where implementors have 
    come up with different interpretations of the ODF 1.1 spec, the 
    application can chose to come up with its own interpretation or ask the 
    user - that is not of concern to this group. (There also is a 
    meta:generator element that implementors may use in this scenario.)
    
    With regards to ODF 1.2 documents in ODF 1.1 applications, it is in my 
    opinion useful to look at two cases:
    (a) Documents including new elements/attributes not present in 1.1
    (b) Documents constrained to the 1.1 vocabulary
    
    In the case of (a), I do not want to guarantee that an old application 
    will display the document like a 1.2-aware application. This is both 
    unrealistic an infeasible. We should do our best to design new features 
    in a way that allows old applications to "gracefully degrade", rather 
    than completely breaking access to the document.
    
    The case of (b) is largely unproblematic, except for situations, in 
    which different ODF 1.1 applications implement certain aspects of the 
    specification in a different way - whether this is due to ambiguities in 
    the specifications of implementation errors is not relevant. We as a TC 
    cannot change these old applications, and an interoperability 
    disagreement among two 1.1 applications cannot be addressed by anything 
    that we specify for ODF 1.2.
    
    The lists and numbered-paragraph proposals that have been created by 
    openoffice.org and koffice developers are very much in-line with the 
    view presented above. They strike a balance between providing a good 
    design for our new specification. ODF 1.2 applications will not have 
    much burden when importing old documents and ODF 1.1 applications will 
    be able to display documents in a gracefully-degrading manner. If none 
    of the new constructs are used, the old applications will behave as 
    always. If the new constructs are used, they will be ignored, yielding a 
    presentation, that is degraded when comparing to the presentation 
    offered by a newer 1.2-compliant application. This can from my point of 
    view be accepted.
    
    I would welcome if TC members would indicate whether their view 
    regarding these matters is in line with what was presented above so that 
    we may use the resulting guidelines to come to a conclusion regarding 
    the ongoing debate about lists and numbered-paragraphs - hopefully being 
    able to vote on a proposal in the next call.
    
    Bests,
    Lars
    -- 
    Lars Oppermann 


  • 2.  Re: [office] Concerning backwards compatibility in odf 1.2

    Posted 03-29-2007 14:18

    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?

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

       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?

    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.

       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?

    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.  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.

       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?

    This is a question about degrading gracefully.  This will not work in the general case.  For example, an ODF 1.2 document would be using the standard ODF 1.2 OpenFormula spreadsheet formulas.  But no ODF 1.0 editor understands these.

    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.  

    -Rob

    Lars.Oppermann@Sun.COM wrote on 03/28/2007 04:56:41 AM:

    > Dear TC,
    >
    > We concluded in our last conference call, that many of the problems that
    > we are seeing with the debate about lists and numbered paragraphs
    > circles around the various notions about the guarantees that we are
    > willing to make concerning the behavior of applications that were
    > implemented with ODF 1.0/1.1 in mind when they are to open an ODF 1.2
    > document.
    >
    > There has also been the question of ODF 1.1 in ODF 1.2 applications,
    > which I do not view as a problem at all. An ODF 1.2 Application can tell
    > an ODF 1.1 document from an ODF 1.2 document by looking at the (now
    > required) version-attribute in the office:document element. The
    > application can then act accordingly. In cases, where implementors have
    > come up with different interpretations of the ODF 1.1 spec, the
    > application can chose to come up with its own interpretation or ask the
    > user - that is not of concern to this group. (There also is a
    > meta:generator element that implementors may use in this scenario.)
    >
    > With regards to ODF 1.2 documents in ODF 1.1 applications, it is in my
    > opinion useful to look at two cases:
    > (a) Documents including new elements/attributes not present in 1.1
    > (b) Documents constrained to the 1.1 vocabulary
    >
    > In the case of (a), I do not want to guarantee that an old application
    > will display the document like a 1.2-aware application. This is both
    > unrealistic an infeasible. We should do our best to design new features
    > in a way that allows old applications to "gracefully degrade", rather
    > than completely breaking access to the document.
    >
    > The case of (b) is largely unproblematic, except for situations, in
    > which different ODF 1.1 applications implement certain aspects of the
    > specification in a different way - whether this is due to ambiguities in
    > the specifications of implementation errors is not relevant. We as a TC
    > cannot change these old applications, and an interoperability
    > disagreement among two 1.1 applications cannot be addressed by anything
    > that we specify for ODF 1.2.
    >
    > The lists and numbered-paragraph proposals that have been created by
    > openoffice.org and koffice developers are very much in-line with the
    > view presented above. They strike a balance between providing a good
    > design for our new specification. ODF 1.2 applications will not have
    > much burden when importing old documents and ODF 1.1 applications will
    > be able to display documents in a gracefully-degrading manner. If none
    > of the new constructs are used, the old applications will behave as
    > always. If the new constructs are used, they will be ignored, yielding a
    > presentation, that is degraded when comparing to the presentation
    > offered by a newer 1.2-compliant application. This can from my point of
    > view be accepted.
    >
    > I would welcome if TC members would indicate whether their view
    > regarding these matters is in line with what was presented above so that
    > we may use the resulting guidelines to come to a conclusion regarding
    > the ongoing debate about lists and numbered-paragraphs - hopefully being
    > able to vote on a proposal in the next call.
    >
    > Bests,
    > Lars
    > --
    > Lars Oppermann <lars.oppermann@sun.com>               Sun Microsystems
    > Software Engineer                                         Nagelsweg 55
    > Phone: +49 40 23646 959                         20097 Hamburg, Germany
    > Fax:   +49 40 23646 550                  http://www.sun.com/staroffice


  • 3.  Re: [office] Concerning backwards compatibility in odf 1.2

    Posted 03-29-2007 19:05
    On 29/03/07, robert_weir@us.ibm.com 


  • 4.  Re: [office] Concerning backwards compatibility in odf 1.2

    Posted 03-29-2007 20:53

    Hi Dave,

    I must admit that I was not considering the idea of time travel, but it is a thought.

    In general I'm not too far off from what you are stating.  We don't want to be trapped by earlier versions of the format, and be unable to solve real problems by the necessity of perpetuating old mistakes.  Other companies with other legacy formats have that problem, and it is no end of trouble for them.

    But I think we also need to consider that we're giving out three ODF versions within a year, which is a pretty good pace.  There needs to be some semblance of stability, and the ability for the user to have reasonable expectations of forwards and backwards compatibility in such a short time frame.  One way we can help set these expectations is by adopting a clear TC on what type of compatibility guarantee we're making with any new version of the standard.  This may not be the same guarantee with every update.  Maybe we track that with major and minor version numbers, and we make one set of guarantees with minor version updates, and few or no guarantees with major number updates.  ODF 1.2 is feeling to be like a major version update.  I sometimes wonder if it should be called ODF 2.0.

    -Rob


    "Dave Pawson" <dave.pawson@gmail.com> wrote on 03/29/2007 03:04:49 PM:

    > 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


  • 5.  Re: [office] Concerning backwards compatibility in odf 1.2

    Posted 03-30-2007 07:42
    On 29/03/07, robert_weir@us.ibm.com 


  • 6.  Re: [office] Concerning backwards compatibility in odf 1.2

    Posted 03-30-2007 08:10
    On Friday 30 March 2007 09:41, Dave Pawson wrote:
    > Yes, but ODF is still settling down? I'd hope that we can be allowed a
    > little leaway for the first few iterations?
    > Is there a way we can have minor and major releases to minimise
    > the impact on users who need that level of stability?
    
    I personally got the impression we are doing pretty good.  The 4 questions Rob 
    asked I could answer positively for lists, for example.
    With efforts like the formula SC only adding their results when its done means 
    that we don't have ugly backwards compatible issues. Or as one KDE person 
    always says (paraphrase);
     We're not a company, we just produce better [specs] at less costs.
    
    :)
    -- 
    Thomas Zander
    


  • 7.  Re: [office] Concerning backwards compatibility in odf 1.2

    Posted 03-30-2007 08:23
    On Thursday 29 March 2007 22:52, robert_weir@us.ibm.com wrote:
    >  ODF 1.2 is feeling to be
    > like a major version update.  I sometimes wonder if it should be called
    > ODF 2.0.
    
    The negative result of such a rename would be that people expect a major 
    version to break backwards compatibility; so I don't think its a good idea.
    
    If in the future we have various minor fixes and changes we can release an 
    1.2.1 release to make clear that that is a minor update.
    -- 
    Thomas Zander