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: 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 Brauer, Technical Architect Software Engineering
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500

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]