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] Versions and ODF-Next: was Thoughts on ODF-Next


On Tue, 2011-01-18 at 09:34 -0500, robert_weir@us.ibm.com wrote:
> Patrick Durusau <patrick@durusau.net> wrote on 01/18/2011 07:54:58 AM:
> > 
> > Greetings!
> > 
> > I have changed the subject line to make it a little more obvious what is
> > under discussion.
> > 
> > What I am missing in this discussion is what advantage is there to
> > having a designation, say ODF 1.3, that identifies *different* versions
> > of ODF?
> > 
> Advantage:   If there are more than one vendor who can read the same draft 
> of ODF then they can handle in a more coordinated way any incompatible 
> specification changes between that draft and subsequent versions.

Sorry, that went by rather quickly.

Do you mean that having one label, say ODF 1.3, then vendors can get
together to handle inconsistencies between the "editions" that lead up
to the final 1.3 "version?"

I suppose but where does that leave users who only see "1.3?"

> > Or to put it differently: What is the disadvantage in *accurately*
> > identifying the version of ODF that is being implemented?
> >
> Disadvantage:  This may not be sufficient.  In practice, early 
> implementations of a draft may have incompatibilities as much caused by 
> differing interpretations of the same specifications as by the use of 
> different versions of the specifications.  That is one reason why we 
> encourage early implementation, why we have plugfests, etc.  Merely 
> knowing that someone has implemented "ODF 1.3 CSD01" may not tell enough. 
> You may need to look also at the <meta:generator> element in meta.xml.
> Also, we need to remember that a given editor may actually implement 
> several versions of ODF, and even a given ODF document may be conformant 
> to several versions of ODF.  So having a string that says "I am conforming 
> to this version of the spec" will not reflect the fullness of the facts 
> and circumstances.  If a document conforms to ODF 1.0, 1.1 and 1.2 
> (including all CSDs of them) as well as ODF 1.3 CSD01, then any single 
> value of a "version-supported" attribute would be a lie.  And what if 
> (hypothetically) there was an error in ODF 1.2 CSD-02, making the document 
> conformant to all previous drafts except that one.  Even a 
> "latest-version-conformant-to" attribute would not work there. 
> So no objections per se to adding an attribute for this kind of 
> information, though I don't see in practice how it could be made accurate 
> or useful.

I wasn't necessarily suggesting the attribute approach, which as you
point out, may have problems.

It could be that we simply have to tell users to view claims of
conformance to non-final versions with a grain of salt. 

That unless and until a final version appears, there is a greater burden
on users of investigating what they are being promised by a particular

Hope you are having a great day!


PS: Cautioning users might be a useful exercise in any case. Conformance
clauses are not self-executing and users need to compare implementations
to conformance clauses or undertake other testing of conformance before
reaching conclusions with regard to conformance. 

Patrick Durusau
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)

Another Word For It (blog): http://tm.durusau.net
Homepage: http://www.durusau.net
Twitter: patrickDurusau
Newcomb Number: 1

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