Re: [opendocument-users] RE: Foreign elements and attributes

[Jesper Lund Stocholm <4a4553504552@gmail.com>]

Alex, all

2009/3/4 Alex Brown <alexb@griffinbrown.co.uk>:
>>
>> 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.

Yes - so the problem is dual-edged:

The nifty thing about XML is that it is "endlessly extensible".
However, that is also the kindof annoying thing when it comes to
discussing these conformance classes.

So if we for a moment accept extensibility as the basis of XML and
just look at the suggested two conformance classes, I think the
benefit of having two conformance classes are:

1.
It has an appealing tone to it. It might sound like kindof a stupid
claim, but we (or, in this case, the ODF TC) should never
underestimate the power and will of users. If the ODF TC can come up
with a sensible argument for the use-case benefits of dual conformance
classes of users, they'll likely adopt it. I think Rob's piece on
interop and conformance classes is a step in the right direction, but
he should have made clear that he was referring to a "blue-sky"
scenario and not how dual conformance classes will likely end being
used "in the wild".

2.
(premis: if two conformance classes will be approved, there MUST be
constructed some sort of easy way to detect the class of document
being loaded)
Having two conformance classes will likely gently push document
consumers to implement alert to users when loading different classes
of documents. This will enhance "interop predictability" and make
users more aware the reason for them loosing information. I envision a
stamement to the user upon loading an ODP-document in the shape of
"Please be aware that this document was created in 'MyAPP' and
contains information that could not be processed". Think about the way
modern browsers notify their users of expired SSL-certificates or
phishing-sites.

3.
Section 2) above will push document producers to abide by the rules
and not do short cuts in the form you mentioned.

Now, I think dual conformance classes sounds like a good idea, but ODF
TC must enhance the text describing it to a level that greatly
exceedes the current detail level of ODF 1.2 CD01. There is a lot of
things that need better explanation, as you point out:

a) what content should the extended conformance class represent?
b) will text-documents containing mathematical content belong to the
extended class?
c) will document containing scripts belong to the extended class?

In short, will documents containing content not described by the spec
be of conformance class "extended"? I think the only logical
consequence of this will be to require usage of the
<config-item-set>-elements to result in belonging to the extended
conformance class. ODF 1.2 CD01 has this description of these
elements:

"The <office:settings> element may contain one or more
<config:config-item-set> elements, each of which represents a set of
application settings."

Now, if you look at how major implementations use these setting
elements (but not Microsoft Office 2007 SP2, btw), you will notice
that they all stuff application specific data into this "trash bin"
ranging from simply specifying line height of previous versions of OOo
(OpenOffice 3.0) and dumping Base64-coded binary printer blobs into it
(Lotus Symphony 1.0).

Since these are all dofficult to process in an interoperable fashion,
usage of this section should put the document into the extended
conformance class.

-- 
Jesper Lund Stocholm
www.idippedut.dk
SC34/WG4 http://www.itscj.ipsj.or.jp/sc34/wg4/