RE: [office] ODF 1.2 Single-Level Conformance and Law of Unintended Consequences

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

This also reminds me of another debate, called floor=ceiling.  

Floor=Ceiling was debated in the early days of initial COBOL standardization
efforts and it continued for a while.  I can't recall which side of the
debate Committee Chair Howard Bromberg held onto and if he flipped at any
time.  

Generally, producers of implementations did not look kindly at floor=ceiling
and user communities (but not all of them) and especially standards sheriffs
of various persuasions wanted floor=ceiling.  Of course, COBOL was
modularized and there were definite implementation-specific provisions
(COMPUTATIONAL-1, COMPUTATIONAL-2, ... and similar aspects coming to mind),
so I am not sure how much it was felt that floor=ceiling was achieved, in
the end.   

At that time, I was a big proponent of floor=ceiling, even though the first
programming-language standard (for Fortran in 1966) had two levels.  In
reality, producers rarely said they were doing Basic Fortran with
extensions, they invariably claimed Full Fortran with a few
rarely-explicitly-defined missing features and whatever extensions they were
promoting.  That propensity seems to be alive and well in the
document-format world, too.

So you could persuade me to align with floor=ceiling, although my concern is
that the provision and specification around foreign elements and arbitrary
style and metadata additions already exist (and I can see lots of processors
wanting to stay with metadata.xml rather than take the RDF route for some
simple metadata feature the expression of which in RDF is no more standard
but far more effort).  I am not convinced that it is wise to force RDF
metadata into routine processing by legislation in the standard.  It would
be better to see how eagerly implementations support it before we lock out
an existing easy case for an easy problem.  [With regard to my objection to
magical thinking about RDF metadata, I don't see any way it can be used to
introduce styles as currently formulated such that an implementation is
likely to notice it even happening, in contrast with arbitrary
style:*-mumble.]

 - Dennis

PS: If we are going to remove or deprecate some of these because they have
not been seen in use or to be useful, we should maybe start filtering other
features that seem to have no implementations.  Or perhaps it is better to
consider such breakage in moving to an ODF 2.0 some day.

PPS: I concede that the law of unintended consequences can work both ways,
considering the proclivity of producers for wanting to claim support of the
latest and greatest and of users to having it available as a check-off.

-----Original Message-----
From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org] 
http://lists.oasis-open.org/archives/office/200901/msg00134.html
Sent: Monday, January 19, 2009 10:11
To: 'robert_weir@us.ibm.com'
Cc: 'office@lists.oasis-open.org'
Subject: RE: [office] ODF 1.2 Single-Level Conformance and Law of Unintended
Consequences

Thanks Rob,

With regard to current allowances of implementation-defined features, the
choice of schema matters.  The "strict" schema actually removes some areas
where implementation-defined extensions were explicit in the schema itself.
(And, for a different example, I assert that it is a feature, not a
limitation, to have omission of table:protection-key-digest-algorithm mean
that the hash function that produces the table:protection-key is
implementation defined [and also upward-compatible from 1.1 as well].)  

If we leave the non-strict schema as the only one, that is a different story
since it is the schema against which Conforming Document is defined in 1.1.
Also, the appearance of optional arbitrary metadata elements and
style:*-properties is explicit in the schema and in the 1.1 conformance
clause, which goes on to say that a conformant processor should preserve
such material.

I don't see this language in the current conformance clause.  So that is
something we need to be clear about with regard to 1.2 and the chosen
schema.

I think this is like one of those strict-constructionism debates.  I have no
idea why these provisions and the foreign element provisions are in ODF
1.0/1.1, nor the problems that were being addressed.  I can see benign and
valuable uses of them, but that is an academic point.  I just don't like
fixing something by breaking it.  With regard to interoperability, I don't
think the issue is even close to hinging on what the spec says a conformant
document is, strictly or loosely.

I must remember to point out that there is no advice around what it means to
provide no semantic support for something that is part of a conformant
document, while there is clear advice around dealing with an unrecognized
foreign element.  It would be nice to be able to say that if no semantic
support is provided for a feature of a conformant document, the processor
should treat it using the rules for foreign elements and  attributes.  This
also works for unrecognized features using ODF-specified namespaces too.
(The office:process-content advice could be extended for that as well,
rather than deprecated.)

 - Dennis

-----Original Message-----
From: robert_weir@us.ibm.com [mailto:robert_weir@us.ibm.com] 
http://lists.oasis-open.org/archives/office/200901/msg00131.html
Sent: Monday, January 19, 2009 09:18
To: office@lists.oasis-open.org
Subject: Re: [office] ODF 1.2 Single-Level Conformance and Law of Unintended
Consequences
http://lists.oasis-open.org/archives/office/200901/msg00130.html
"Dennis E. Hamilton" <dennis.hamilton@acm.org> wrote on 01/19/2009 
11:44:34 AM:

> 
> That was a very interesting discussion on conformance with regard to
> having a single-level conformant document.
> 
> I want to reaffirm that, with the single-level approach, we need to 
> deal with all of those places where implementation-defined features 
> are allowed.  (Another example is in the use of alternative 
> renditions and objects where there is currently no specification of 
> MIME types for recognized ones.)
> 

The TC may certainly address other areas where ODF currently has 
implementation-defined features, but I wouldn't say this is a necessity. 
Remember, the proposal for "loosely conformant" documents dealt with only 
a single dimension of extensibility, that done by the allowance of foreign 
elements and attributes.  If we do not allow such extensions in conformant 
ODF 1.2 documents, then the status quo with regards to other 
implementation-defined behaviors remains unchanged unless the TC wishes to 
address those areas separately.

[ ... ]