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