[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [opendocument-users] RE: Foreign elements and attributes
Jesper, all, > In my opinion it does not solve it. Please consider the Greek comment > 14 on OOXML from the DIS29500 process. It dealt with the "equationXML" > attribute. I am particularly thinking about the > "hydration/dehydration"-technique described. Leaving a "loop-hole" in > allowing foreign attributes and not elements would only force > implementers to add all of their extensions in attribute values. > > I think extensibility is really important - as does most of you, but > I'd much rather have the existing suggestion with two conformance > classes than one where extensions are distilled to fit into an > attribute value - which could be the consequence. > > And I still haven't heard why implementers are not satisfied with a > solution where they get the ability to extend ODF to suit their needs. > They just need to call their document "Conformant to OpenDocument > Extened conformance class". Personally, I have no problem with the two conformance class argument in itself. It is the way it has been done and the spin surrounding it that bother me. Already we have some spin going on in Rob's latest blog where he likens this new kind of conformance to pure organic food free from additives, and implies it offers us some kind of better interop promise. ("[extensions] are difficult or impossible to use in an interoperable fashion, at least by those who do not know the secret details of the extension. [...] it is important to put control firmly in the hand of the consumer of ODF products, so they can make the appropriate choice for themselves.") The fact is that an ODF document that conforms to this new restricted conformance class is, practically, just as lousy a basis for conformance as existing ODF documents. There are, I think, three main reasons for this (in ascending order of seriousness): (1) There are always techniques for abusing an XML format; processing instructions, comments, base64 content in metadata, etc. People are endlessly creative in such matters. (2) ODF *still* defines no scripting language, so any high-value document which uses scripting isn't going to be interoperable (also, one can of course write a script to layer in whatever features and functionality one wants, while remaining strictly in accord with the new "pure" conformance class - one can even embed a load of XML in one's "script", of course; this is just a mile-wide back door for non-interoperable extensions in the pure conformance class). I, for one, shall certainly be arguing the case for insisting on ODF 1.2 having well-defined scripting mechanisms. (3) The "pure" conformance class allows implementations to ignore features: a conforming consumer "need not interpret the semantics of all elements, attributes and attribute values" (1.4.4); so an office application with its "pure ODF conformance" sticker can quite legitimately omit to do difficult stuff (like mathematics, tables or footnotes) if the developers want. So I think users need to understand, very clearly, that an ODF document/app of *either* conformance class has an EXTREMELY WEAK CLAIM TO INTEROPERABILITY. The "pure ODF conformance" sticker would be at best valueless and at worst positively misleading. So what I'd like to see is some real effort from the TC going into resolving this problem ... - Alex. -- Alex Brown Convenor, ISO/IEC JTC 1 SC 34 WG 1 Editor, ISO/IEC 19757-5 (Extensible Datatypes)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]