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


On 02/02/09 17:04, Dennis E. Hamilton wrote:
> 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.

One could do so, but this would only mean little if not no improvements 
compared to the situation on ODF 1.1.

> 
> 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.

If you mean the office:process-content attribute here: This attribute 
actually makes it impossible to extend the validation to documents that 
contain foreign elements using NVDL, which appears to be a very 
reasonable goal. For this reason, this attribute has been deprecated 
even in the proposals which included a loose conformance.

Best regards

Michael

> 
> 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
> 
> Michael,
> 
> 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:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
> 


-- 
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]