OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

opendocument-users message

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