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] Thoughts on ODF-Next

On Tue, 2011-01-18 at 01:04 -0700, Michael Brauer wrote:
> Andreas J. Guelzow wrote:
> > On Mon, 2011-01-17 at 18:24 -0700, Patrick Durusau wrote:
> >> On Mon, 2011-01-17 at 11:59 +0100, Michael Brauer wrote:
> >>> Andreas J. Guelzow wrote:
> >>>
> >>>> While I realize that we can't mandate that and in fact have no control
> >>>> over whether a vendor calls their format ODF1.3 or whatever, I thin kwe
> >>> A CSD approval is the first level of approval in the OASIS TC process.
> >>> So, if we approve an ODF 1.3 draft as CSD, and if an implementor 
> >>> implements this CSD, why shouldn't that be called ODF 1.3? How would you 
> >>> call it instead?
> >>>
> >> I don't think successive CSDs would all be called ODF 1.3, without more.
> >>
> >> See the Naming guidelines,
> >> http://docs.oasis-open.org/specGuidelines/ndr/namingDirectives.html, in
> >> part:
> > 
> > Patrick, we are not talking about what the TC or OASIS calls the various
> > CSD but what the version string would be that is used in ODF files
> > created by vendors that implement ODF1.3CSD1. I don't think the version
> > string should be just "1.3"
> What we are developing are OASIS standards, and the CSDs are just 
> intermediate draft on our way to the OASIS standards. I'm not in favor 
> of using different versions strings, since this may be misinterpreted as 
> giving CSD more weight than they have.

If we do not distinguish CSDs from approved standards the version string
is useless. It was my understanding that the version string can be used
to determine the meaning of the various elements by providing an
unambigious indicator of the document describing the elements. 

> But there are other options. We may for instance add an attribute that 
> maybe used in content.xml, styles.xml, etc. and which links to the 
> schema against wich the file is valid. All schemas we approve will be 
> available at docs.oasis-open.org, and the name of the schema contains 
> the CSD number. It therefore unambiguously identifies the CSD that has 
> been used for the implementation that created a document.
> The same method could be used to link extended ODF documents to a schema 
> that includes the used extensions. This would allow to validate such 
> documents, what is not possible right now.

This will make the situation even worse: having an attribute whoese
value can be essentially an arbitrary schema URL does not allow us to
use that string to recognize the meaning of the attributes since we are
likely to encounter URLs we don't know.

Unless there is some guaranteed way for us to recognize that a given ODF
file can be interpreted as described in a certain ODF description,
support for ODF becomes virtually impossible.



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