Conformance Clause Proposal: Clarifications, Extension features

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

Dear TC members,

regarding the discussion about the conformance clauses, and regarding 
the latest proposal, I would like to provide a few clarifications:

1. The "conformance" clause does forbid foreign elements and attributes. 
It does not forbid RDF metadata. It does not forbid application 
settings. It does not forbid adding other streams to ODF packages. If 
anyone finds something in the proposal that could be understood as that 
we forbid any of these things, please let me know what this is.
2. The reference to the formula specification indeed is something like a 
placeholder that may have to be adapted when the formula specification 
is finished. I have added it, because there must be some language 
regarding formulas, and we have to start somewhere.

When I look through the discussion, then it seems to me that what is 
mainly under discussion is the name of what is currently called "host 
language conformance"? Is that correct? Or are the TC members that would 
disagree to the proposal if we would have a different name where? If 
not, I suggest that we concentrate on finding a different name that is 
acceptable for all of us?

Where is also a larger discussion regarding whether or not extensions 
are good or bad, and what an application can do with them. I would like 
to share my few on this:

First of all, we must differ between a properly defined extensions 
mechanism, and the use of foreign elements and attributes.

A properly defined extension mechanism has some minimum semantics and 
requirements. The new metadata feature for instances has the semantics 
that the added information is to be interpreted as metadata. It is based 
in RDF/XML and well defined set of attributes, so that a consumer can 
identify metadata subjects, predicates and objects. A consumer therefore 
may not be able to understand what the metadata means, but it at least 
could tell a user that there is metadata, and may ask him whether it 
should be deleted or not. Vice versa, an application that wants to 
support metadata exactly does know what to implement.

Or take the application settings. These are explicitly declared to be 
application specific, and there is a mechanism to identify to which 
application they belong. An consumer therefore does know that the 
information it reads are application settings, and it does know that it 
can safely ignore and remove settings from other applications.

We also have the possibility to add user defined chart types, but again 
with a proper identification mechanism.

Foreign elements and attributes in this discussion are often seen as an 
extension mechanism. Well, of cause, foreign elements can be technically 
used as extension mechanism. But what is missing is a minimum set of 
semantics that allows applications to process them properly. An 
application does not know anything about them. It does not know whether 
they constitute metadata, an proprietary extension, an embedded user 
defined XML instance, or whatever. So, it indeed can do nothing else 
than ignore this data. It can even not really ask the user what to do 
with the data, because which user does a question where she or he is 
asked whether not to keep a certain XML fragment. And who would answer
'yes, keep it' without any knowledge what it is?

It has multiple times drawn a connection between foreign elements and 
customXML in the sense of OOXML. While allowing foreign elements and 
attributes would indeed permit embedding custom XML instances into an 
ODF document, I don't think that the current definition of foreign 
elements and attributes in ODF (1.1) is a proper definition of a 
customXML feature. For a customXML feature I would at least expect an 
identification mechanism, and more important, a list of those places 
where they can be actually embedded. Without that: How should an 
application know that some foreign elements are in fact custom schemas? 
Even an application that has such a feature implemented would not know 
whether or not a set of foreign elements is a custom schema, or any 
other data which another application has saved where. And how should one 
application implement a customXML feature that is compatible with the 
one of another application if it does not know where the other 
application support customXML and which of the XML elements and 
attributes are administrative data for the feature and those real custom 
data?

So I agree to Rob here: If we want such a feature, then we should define 
it, but we should not use this as argument for a loose definition of 
conformance. The same holds if we identify other areas where extension 
appear reasonable, but where we do not have any extension mechanism in 
place.

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