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


Patrick Durusau <patrick@durusau.net> wrote on 01/18/2011 10:45:34 AM:
> > 
> > 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?"
> 


I think you would need either:

office:version="1.3 (CSD01)"

or

office:version="1.3.1"


or

office:version="1.3"

along with

office:draft-version="CSD01"


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

The practical problem with that approach is that users don't read the 
spec.  In fact, most don't even read the product manual.  Maybe if the 
file save dialog said "Save as ODF 1.3 (CSD03)" and gave a repressible 
warning message the first time, maybe that would work.   An implementation 
that was concerned about this issue and wanted to inform its users about 
the trade-offs of saving to a pre-final version of the standard could do 
that.  There is nothing in the ODF specification that prevents a vendor 
from doing this today.

-Rob


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