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] ODF 1.2 Version Significance Proposal - COMPLETE UPDATE

Michael, I accept your remarks, and will make the one correction (office:document-content) and the one deletion (regarding later specifications).  I agree that we can let the question of redundancy be resolved when we are reconciling the committee-draft text internally before public review. 

 - Dennis

-----Original Message-----
From: Michael.Brauer@Sun.COM [mailto:Michael.Brauer@Sun.COM] 
Sent: Monday, January 12, 2009 04:45
To: dennis.hamilton@acm.org
Cc: 'ODF TC List'; 'Rob Weir'
Subject: Re: [office] ODF 1.2 Version Significance Proposal - COMPLETE UPDATE

Hi Dennis,

thanks for updating your proposal. I have only a few minor comments 
regarding this updated proposal.

On 01/11/09 00:24, Dennis E. Hamilton wrote:
> [January 10 complete text (in wikiText format)[
> === 18.588 The office:version attribute ===
> The office:version attribute identifies the version of ODF specification that defines the associated element, its schema, its complete content, and its interpretation.
> The office:version attribute '''shall''' be present in 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. The value of the office:version attribute '''shall''' be "1.2".

It must read <office:document-content>, etc. rather than just 

I still think we should not repeat normative that is already said in the 
schema, but that issue is as minor for me that I'm also fine with the 
current text.
> '''Note:''' Notwithstanding the occurrences of office:version="1.2", an ODF 1.2 document that relies solely on features of a previous ODF specification that are upward-compatible into ODF 1.2 can also be interpreted correctly under that earlier specification by taking the office:version attribute as everywhere omitted or as identifying that earlier version instead. See also Appendix H, Changes From Previous Specification Versions (Non-Normative).
> '''Note:''' 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.  

 > 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. In none of these cases do the elements comprise an ODF 1.2 document.

We should omit this. We don't know what future ODF version will look 
like, and the information that is provided does not add any hint how to 
handle such documents. An ODF 1.2 document must have the value "1.2". 
One that does have another value is not an ODF 1.2 document, since it 
does not validate against the ODF 1.2 schema. We therefore don't have to 
repeat that it is not an ODF 1.2 document.

> In any case where an apparent ODF document does not provide the office:version attributes and values required for ODF 1.2 documents, 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 for which the same-named ODF 1.2 features are incompatible '''need not''' be accepted.  If accepted, an ODF 1.2-incompatible feature '''should''' be cast into an equivalent but ODF 1.2-compatible form.    See Appendix H, Changes From Previous Specification Versions (Non-Normative), as well as previous specifications and any approved errata for them.
>    * Any elements and attributes that are neither recognized, accepted, nor supported by the implementation, even though identified in XML namespaces defined for use in ODF 1.2 documents, '''should''' be treated in accordance with the rules for foreign elements and attributes (section 1.4). 
>    * Subsequent processing '''should''' be as if the accepted document were exactly the ODF 1.2 document derived in this way. 

These requirements are all reasonable, but I'm not sure if we really 
need them, or all of them. Some of the requirements will be covered by 
the conformance clauses. Others are just a matter of fact if we do not 
prohibit that an ODF 1.2 application tries to read non ODF 1.2 files.

Anyway, I'm fine if we agree on these requirements for now, if we 
reserve the option to revise this if we have agreed on the conformance 
clauses itself.

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

To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:

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