Re: [office] ODF 1.2 Version Significance Proposal

[Michael Brauer - Sun Germany - ham02 - Hamburg <Michael.Brauer@Sun.COM>]

Hi Dennis,

thank you very much for the proposal. Please find a couple of
comments/suggestions below:

On 05.01.09 01:24, Dennis E. Hamilton wrote:
> I have been careless in having a reviewable version of my proposal on ODF 1.2 Version Significance available in advance of the January 5 coordination call.  I also broke my promise to have this proposal "in a complete form, and under discussion on the list, by January 1, 2009."
> 
> PROPOSED CONTINUATION ON THE PROPOSAL
> 
> The proposal has been updated with complete text for the description of "office:version":
> http://wiki.oasis-open.org/office/ODF_1.2_Version_Significance
> The proposed text is also included below (in wikiText).
>   
> I recommend that this proposal be discussed on the list between now and the January 12 call.  Discussion on January 5 is welcome, but I accept that most participants will have not had an opportunity to give the proposal much consideration at that time.
> 
> I do not propose to deal with "manifest:version" here.  We can look at that, if necessary, as part of reviewing Part 3 of the ODF 1.2 specification.  
> 
> PROPOSED TEXT
> 
> == Requested changes to the ODF Standard ==
> 
> {{{ This version of the proposal does not address the manifest:version attribute.  This should be dealt with separately. }}}
> 
> Replace the text in section 18.588 of OpenDocument-v1.2-draft7-13.odt with the following text:
> 
> === 18.588 The office:version attribute ===
> 
> The office:version attribute is required for each and every <office:document>, <office:content>, <office:document-styles>, <office:document-meta>, and <office:document-settings> element in the XML documents that comprise an ODF 1.2 document.  

This is information that we have already in the schema and the element
list  we generate from it. I'm wondering if we really have to repeat
this information in prose.


> The value of the attribute must be "1.2" in those occurrences.


> 
> An ODF 1.2 document, notwithstanding occurrences of office:version="1.2", CAN also be acceptable as a document of a previous ODF version when only ODF 1.2-compatible features of the earlier version are relied upon for the ODF 1.2 document.  

Whether an ODF 1.2 document is acceptable as an ODF 1.1 or ODF 1.0
document depends on whether it meets the conformance criteria we have
defined in these specifications, and only on that. We are defining ODF
1.2 here. We have defined ODF 1.2 in a way that an ODF 1.2 document can
be understood by an ODF 1.0/1.1 application, that's true. But we are not
re-defining or replacing ODF 1.0/1.1 in the meaning that the ODF 1.2
specification in addition to ODF 1.2 also defines what an ODF 1.1 and
ODF 1.0 document is. It only defines what ODF 1.2 is, while the ODF 1.1
specification continues to define what an ODF 1.1 document is, and the 
ODF 1.0 specification continues to define what an ODF 1.0 document is.

Having that said. I think it may be reasonable to provide the 
information that an ODF 1.2 document under certain circumstances is 
understood by an ODF 1.0/1.1 application, but I think we should do so as 
a note rather than as a normative statement.

> The treatment of such documents by processors designed to implement
> earlier versions of ODF is implementation-specific and is not subject
> to ODF 1.2 conformance requirements.

Actually, the treatment of such documents is subject to the ODF 1.0 and
1.1 specifications. Whether an ODF 1.2 application additionally supports
ODF 1.0 and/or 1.1 is implementation specific. It may, or it may not. It
is nothing where we should make any assumptions or statements in the ODF
1.2 specification

> 
> When an office:version-requiring element has office:version="1.1" the element and its content are based on the OpenDocument v1.1 specification [ODF11].  
> For office:version="1.0" the element and its content are based on the
> OpenDocument v1.0 specification [ODF10].

> When an office:version-requiring element has office:version omitted,
> the element is based on a version of the OpenDocument specification
> earlier than ODF 1.2.

These all are observations that repeat what we say in the ODF 1.0 and
1.1 specifications. Like above, I have no objections to have these as
notes, but I think we must not have these as normative statements.

I know that we have a similar language in the current specification. I
consider this to be an error, too.

>  Any treatment of these cases in accordance with the earlier ODF
> specifications by an implementation that supports ODF 1.2 is
> implementation-specific.

This essentially says what I have added as comment above, so maybe we
can take this is basis for an informative note.

> 
> When an office:version-requiring element has an office:version attribute with value other than one of "1.0", "1.1", and "1.2", the element and its content are based on an OpenDocument specification later than ODF 1.2.  Any treatment in accordance with such specifications by an implementation that supports ODF 1.2 is implementation-specific.

Regarding future versions, I think we have to differ between two things. 
First, what does an application that supports ODF 1.2 if it is asked to 
process a document that identifies itself as a document that conforms to 
a new version of ODF? This indeed is implementation specific. The 
application may have an implementation for that ODF version and it may 
take that. Or it may just try to read the document anyway. We should not 
make any assumptions here.

The other question is what happens if such a document is read by an ODF 
1.2 implementation. For this case I think we should have some clear 
statements what happens with elements and attributes not defined by ODF 
1.2. I have added some language for this to my recent conformance clause 
proposal. I think we should align your suggestions below with what I 
have in the conformance clause proposal. What seems to be essential to 
me to note for the version attribute is that an conforming consumer is 
allowed to consume documents that have other version attribute values 
than "1.2", and that it in this case should behave as if the attribute 
value is "1.2". This is your first item below.

> 
> In any case where an apparent ODF document is not specifically an ODF 1.2 document based on the required occurrences of office:version attributes, an ODF 1.2 implementation MAY process the document as if it is an ODF 1.2 document:
>   * In doing so, the implementation SHOULD behave as if the requisite office:version="1.2" attributes are present. 
>   * Any elements and attributes based on earlier versions of ODF that are incompatible with the corresponding ODF 1.2 features NEED NOT be accepted.  If the incompatible form is accepted, it SHALL be accepted as if cast into an equivalent but ODF 1.2-compatible substitute form.
>   * Any elements and attributes that are not defined for ODF 1.2, even though occurring in XML namespaces defined for use in ODF 1.2 documents, SHOULD be treated in accordance with the rules for foreign elements and attributes. 
> 
> == Schema changes/additions: ==
> 
> The current schema has office:version="1.2" be an office-document-common-attrs non-optional attribute with required value.  This proposal makes no change to the schema.

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