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 06:27 -0700, Michael Brauer wrote:
> On 18.01.2011 09:17, Andreas J. Guelzow wrote: 
> > 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. 
> >   
> What we are developing will be an ODF 1.3 OASIS standard, or maybe a
> 2.0. All committee drafts will be intermediate drafts, and 
> I don't feel comfortable if these get distinct version numbers in the
> schema. Further, A CSD may be send out for public review. It is then
> called a 
> committee specification public review draft. We have seen this for ODF
> 1.2 CSD06, where the same specification also got ODF1.2 CSPRD02. But
> we cannot change the schema between a CSD and a CSPRD. We also cannot
> change the schema when we approve a CSPRD as CS, or when it gets
> approved as OS. So, encoding the state of a specification into an
> attribute value in the schema does not work.

I fail to see why it wouldn't work? If two document are otherwise
identical there is no reason they could not retain the same version
> Beside that, we must not overestimate the issue of incompatible
> changes between CSDs. We are developing ODF for may years now, 
> and the version attribute always was corresponding to the OASIS
> standard we are developing. I'm not aware of any severe issues 
> this caused. If you are aware of any examples where this caused an
> issue, please let us know them, so that we have something real 
> where we can check how we could have avoided the issue.

We must not underestimate them either. The work for 1.2 has shown the
effect OpenOffice.org's decision to ship something called "1.2" had on
(a) the work on ODF1.2 (by essentially restricting the possibility of
providing a better description for some features since "this is not what
we do in OOo") and
(b) created significant problem for us as Gnumeric developers when we
had to handle inconsistencies between the "current" draft and what OOo
wrote into its files. (In addition since users unfortunately perceive
(if incorrectly) OOo as a sort of reference implementation for ODF  we
even had to deal with the fact that when OOo wrote something into a file
it was considered a Gnumeric bug when the interpretation varied.)

Note that I am not talking about difference in schema but in semantics,
ie. what exactly certain elements and attributes mean. For example OO
writes 1.2 chart:interpolation="b-spline" with a meaning that differs
greatly from its precise definition in the latest drafts. The latest
drafts make it clear that the spline passes through the data points
while earlier drafts used the data points as control points only. This
is greatly visible.  

> Further, before a proposal gets into the specification, we, the TC,
> are discussing and reviewing it. Only if we think that the proposal is
> good and stable, 
> we are accepting it. In the past, the vast majority of proposals was
> accepted once, and did never change since when. Changes to accepted
> proposals are the exception. I don't know why this should suddenly
> change.
> > > 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.
> >   
> You have to consider here that it us who defines ODF. We can set up
> whatever requirements or 
> recommendation for the URL what we need is required or useful. If we
> state that conforming documents should or shall reference the schema
> on docs.oasis-open.org that was used by the implementation, then
> implementations have to reference exactly these schemas.

The schemas on docs.oasis-open.org would not include any schemas "that
include the used extensions" so I don't understand how this would work
for your previous suggestion.

> Further, I think all implementors are interested in creating documents
> that are interoperable. Why should anyone use random URL values?

I meant "random URL values" as URL values that can only be discovered by
checking those implementations not by knowledge of the standard and any
committee drafts.
> > 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.
> >   
> I don't agree, but I've made a suggestion how the problem anyway could
> be solved. It's not in the version string for the reasons I've
> outlined below,

There is nothing given below and I disagree with (or at a minimum do not
follow) your reasoning above.


>  but it anyway is a possible solution. If you have an alternative
> proposal that is in line with the OASIS process and the spirit of the
> OASIS standardization process, I'm all ears.

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