[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Regarding Conformance Clauses
Dear TC members, following our discussion regarding the conformance clauses, I would like to provide a few clarifications. But before I do so, I would like to ask you to provide your feedback to the conformance clause proposal wherever possible as specific feedback to one the the proposed clauses, and if possible, supplemented with suggestions how to modify or adapt them. This will make it much easier for me to address it. 1. The only extension point that ODF 1.1 has that is effected by my conformance clause proposals are foreign elements and attributes, that is, elements and attributes that are not defined by the ODF specification, and that may be mixed with ODF elements. Other extension points are not covered by the proposal. 2. Both proposals define a conforming document as one that does not contain any foreign elements and attributes. Both proposal require that a conforming ODF producer is able to produce conforming documents, and both proposals say that a conforming consumer should able to parse documents that contain foreign elements (The last should could be turned into a shall if this is the concern). So, the only (intended) differences between the two proposals are that in the first one, a document that contains foreign elements or attributes may be called a "loosely conforming ODF document", and that a conforming producer may create loosely conforming document in addition to conforming ones. In contrast, in the 2nd proposal, called "alternative proposal", there is no definition for a loosely conforming document. That means that a ODF 1.2 document that contains foreign elements or attributes must not be called an ODF document. Please note that this does not forbid conforming application to produce such documents. They only must not call these documents ODF documents, and of cause, they must be able to produce conforming ODF documents additionally. 3. ODF 1.1 defines two schemas, a strict schema and a non-strict schema. The difference between the two schemas is that the non-strict schema allows arbitrary elements and attributes within <office:meta> and the <style:*-properties> elements, while the strict schema does not. This means that an ODF 1.1 document that validates against the strict schema does not contain any foreign elements, while one that does validate against the non-strict schema may contain foreign elements within <office:meta> and the <style:*-properties> elements. Since ODF 1.1 allows foreign elements and attributes anywhere, the non-strict schema actually would not have been required. To make things simpler, I would suggest that we define a single schema for ODF 1.2. 4. Foreign elements and attributes allow to include other, non-ODF markup into documents. In practice they have never been used for this purpose. Moreover, ODF has support for XForms since ODF 1.0, and support for RDF/XML and RDFa since ODF 1.2. Both feature allow to embed non-ODF data into ODF documents in a standardized way, without any side-effects on parsing and processing the ODF markup, and without causing any difficulties for validating ODF documents. For this reason, I personally think that the use of foreign elements and attributes is no longer required and may be disallowed for conforming documents in ODF 1.2. 5. Foreign elements and attributes allow to add extensions to ODF documents. Since extensions to ODF cause interoperability issues, I believe the better approach than adding non-standardized extensions to ODF is to propose the extension to the ODF TC, so that it gets part of a future version of ODF. To minimize the time until when they get available for implementation, I suggest that we agree to deliver committee drafts which include all proposals that have been accepted so far more frequently than in the past. This would allow implementors to actually implement the most recent draft, which seems to be a better option to me than implementing a standard plus some implementation specific extensions. Best regards Michael -- Michael Brauer, Technical Architect Software Engineering StarOffice/OpenOffice.org Sun Microsystems GmbH Nagelsweg 55 D-20097 Hamburg, Germany michael.brauer@sun.com http://sun.com/staroffice +49 40 23646 500 http://blogs.sun.com/GullFOSS Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer Vorsitzender des Aufsichtsrates: Martin Haering
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]