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 18.01.2011 09:17, Andreas J. Guelzow wrote:
1295338639.2499.7.camel@kirkman" type="cite">
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.

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.

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.
1295338639.2499.7.camel@kirkman" type="cite">
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.

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

1295338639.2499.7.camel@kirkman" type="cite">
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, 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.


1295338639.2499.7.camel@kirkman" type="cite">



Michael Brauer | Oracle Office Development
Phone: +49 40 23646 500 | |
Oracle Office Global Business Unit

ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Rijnzathe 6, 3454PV De Meern, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven

Green Oracle Oracle is committed to developing practices and products that help protect the environment

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