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] Conformance Definitions - Clarification

I think the term "conforming document" should honor the ODF 1.1 definition and remain consistent with ODF 1.0/1.1 and IEC 26300.

Then "strictly conforming document" can be also made normative by including the strict schema as normative and this will be an additional level of conformance but the pre-existing levels match.

The definition of conforming processor in ODF 1.0/1.1 should be preserved and strictly conforming can set a different, lower ceiling.  

These definitions can be done in a way where, apart from breaking changes, existing conformant documents and conformant processors would, with modification of the version attribute, continue to be conformant.  Strict conformance is new and more restrictive and can be as tight as you want.

Finally, the best determination of whether content should be processed, and whether a not-understood element or attribute should be preserved, is the implementation of the foreign element or attribute and the special attribute on preservation (of elements) should be provided by such implementations.

I agree with Michael's discussion about what happens when the document is altered and whether or not foreign elements that might become inconsistent are stricken.  This also applies to xml:id.  The notion of preservation and the conditions where preservation is important and the conditions under which removal is appropriate is not well-defined.

 - Dennis  

-----Original Message-----
From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org] 
Sent: Monday, February 02, 2009 07:44
To: 'ODF TC List'
Cc: 'Michael.Brauer@Sun.COM'
Subject: RE: [office] Conformance Definitions - Procedural Objection

My mistake: the current proposal is at the front of the list and I went looking at the end of the list.

I still want to address these questions.

 - Dennis 

-----Original Message-----
From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org] 
Sent: Monday, February 02, 2009 06:51
To: ODF TC List
Cc: Michael.Brauer@Sun.COM
Subject: [office] Conformance Definitions - Procedural Objection


I have examined your 2009-01-28 Version 7 document.  I cannot figure out in all of that material, what part is the proposal that you are making in the 2009-01-28 list posting on the topic.

1. I would like to see a specific, self-contained proposal document that contains the precise proposal you wish to discuss.  We need a concrete, specific text that is precisely the proposal to know exactly what we are talking about, and we need a week to let it set in.

2. I would like to understand the policy of this TC with regard to breaking changes and the ability to adapt gracefully between ODF 1.0/1.1 documents and ODF 1.2 document in both directions (assuming that there is no essential functionality that is unavailable downlevel).  I note that there have been breaking changes that seem to have no useful purpose other than making 1.2 more complicated and make preservation of 1.0/1.1 documents more difficult (and use of older implementations problematic for processing of so-called 1.2 documents that don't use any 1.2-specific features).

With regard to interoperability, I don't understand the anxiety over foreign elements when the minimum requirement for a conforming processor is that it can fail to provide any interpretation for an arbitrary large set of features under the so-called strict schema.  That strikes me as a far more significant barrier to interoperability than the careful use of foreign elements (e.g., what RDF looks like to a down-level processor and any "1.2"-asserting processor that doesn't support it).

It strikes me that it is far more interesting to deal with how interoperability happens even under strict conformance rather than tinkering with features of ODF 1.1 that are not broken in any way but that are proposed to be broken by the 1.2 "fix."

 - Dennis

Dennis E. Hamilton
NuovoDoc: Design for Document System Interoperability 
mailto:Dennis.Hamilton@acm.org | gsm:+1-206.779.9430 
http://NuovoDoc.com http://ODMA.info/dev/ http://nfoWorks.org 

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]