[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Conformance Clause Proposal: Clarifications, Extension features
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]