[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] Thoughts on ODF-Next
Andreas, On 18.01.2011 09:17, Andreas J. Guelzow wrote: 1295338639.2499.7.camel@kirkman" type="cite">What we are developing will be an ODF 1.3 OASIS standard, or maybe a 2.0. All committee drafts will be intermediate drafts, andIf 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. 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">You have to consider here that it us who defines ODF. We can set up whatever requirements orBut 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. 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">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.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. Michael 1295338639.2499.7.camel@kirkman" type="cite">Andreas --
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 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]