Re: [office] Conformance Definitions - Procedural Objection

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

Hi Dennis,

On 02/02/09 16:44, Dennis E. Hamilton wrote:
> My mistake: the current proposal is at the front of the list and I went looking at the end of the list.

Yes, this is the case. I have included all iterations of the proposal 
and the explanations that has been changed. This shall help to 
understand the considerations that have led to the most recent proposal.

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

Which breaking changes have no useful purpose? The changes regarding 
foreign elements have the purpose to improve the situation regarding 
validation of documents, and to get users a better understanding whether 
or not a document stored by one conforming ODF application does contain 
extensions that cannot be understood by another application. So, it may 
be worth to discuss when and how we make changes here, but in any case, 
they have a purpose.

I also fail to see how this makes ODF 1.2 more difficult. I think the 
opposite is the case. By minimizing the number of schemas, the number of 
conformance levels and by reducing the variants ODF and its 
implementation actually gets easier.

For instance, it is much easier to implement an ODF processor if you 
know that that only elements defined by the schema are allowed, then it 
is if you have to take into account that an unknown element may occur 
everywhere, that even may not be simply ignored.

Best regards

Michael



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