RE: [office] Do we really have that many options in ODF?

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

I'm willing to modify my statement to be

"Everywhere there is a "SHOULD," "MAY," "implementation-defined," and
especially "implementation-dependent" (including when implicit in the
omission of sufficient detail for it to be anything but
implementation-dependent) that is PERMISSION TO CONFORMING PRODUCERS, we
need to consider *any* unnatural acts and barriers that this imposes on
consumers."

To clarify further: I was not distinguishing natural and unnatural with
regard to the history of office productivity software.  That has nothing to
do with it.  I was using unnatural with regard to over-burdening conforming
implementation of interoperable consumers of any standard format by having
to support provisions that no conforming producer might ever emit and that
places consumers at the mercy of prominent producers (who one can expect to
consume what they emit and perhaps little else).

And with regard to Michael's question, "but do we really have that many
options in ODF?" I must say, "Afraid so."

 - Dennis

A HANDY ILLUSTRATIVE EXERCISE

Although I meant this concern for optionality quite broadly, I have a great
example before me in ODF 1.2 Part 3 cd03-rev04-editor-revision.odt.  I will
doubtless add JIRA issues about this and any similar cases that I find.  But
here it is as an example of what there is when one reviews specification
material with a concern over sufficient but not too many options and the
minimization of dependence on out-of-band agreements of any flavor.

1. This is all about 3.8.3 manifest:checksum-type.  This is new to ODF 1.2
and a big improvement, because before this, 3.8.2 manifest:checksum was
implementation-dependent and there was no clue what it was a checksum of.
On the other hand, it is now too complicated in the following respects:

2. Consumer More Constrained than Producers.  The last paragraph of 3.8.3
explicitly REQUIRES consumers to support SHA1/1K and SHA256/1K (by whatever
URI or fixed attribute value is used).  The last paragraph explicitly
RECOMMENDS that producers use an SHA256/1K algorithm and makes no additional
conformance provision on producers in that paragraph.  Note that, with
respect to [xmlenc-core] these are *ALL* "an alternative algorithm as
specified in §5.1 of [xmlenc-core]," so I suppose the last list item in
3.8.3 should really say "any other alternative algorithms as specified in
§5.1 of [xmlenc-core]" (see 4, below).

3. I note that both manifest:checksum-type and manifest:checksum are now
required attributes of the <manifest:encryption-data> element and there are
no defaults.  There probably needs to be more about this in Appendix D so
ODF 1.1 implementers are on notice that the ODF 1.2 story is different.

4. The last bullet in the list in 3.8.3 allows arbitrary additions of
algorithms via identifying URIs, "as specified in section 5.1 of
[xmlenc-core]."  Although confined to "extended conforming packages" I have
already commented on how unnecessary I believe this to be.  There are
adequate ways to deal with this in the event of a breakthrough or breakdown
without writing blank checks.

5. An additional problem consists of the repeated references to sections of
[xmlenc-core].  These are normative references.  So the question is, how
much of the normative provisions of [xmlenc-core] are incorporated via those
normative references?  No profile has been offered for how [xmlenc-core] is
to be applied normatively in ODF 1.2 Part 3.  

6. In the specific case of section 3.8.3 analysis, I note that the defined
values and their defined algorithms for manifest:checksum-type include "an
IRI listed in section 5.7 of [xmlenc-core]."  That section lists 4
algorithms with their URIs.  One (SHA1) is specified to be REQUIRED.  One
(SHA256) is specified to be RECOMMENDED.  The remaining two are specified to
be OPTIONAL.  

7. In addition, [xmlenc-core] has a conformance section that establishes
what support in (6) constitutes conformance to [xmlenc-core] and what that
means for encryptors, decryptors, and applications (ODF 1.2 package
producers and consumers, evidently).

8. Now, it happens that consumers get a free pass here.  There is no
requirement that manifest:checksum actually be checked.  So, as a consumer,
I wouldn't.  As a producer, it appears that I must provide it and that's a
problem.  For security reasons, I don't want to reveal such information.  So
as a producer, I would never implement this encryption.  Wow, that was easy.

9. The issues of profiling [xmlenc-core] are more significant for encryption
(unless you use my get-out-of-jail-free don't-produce-it card).  Section
3.8.3 is an easier, more-straightforward example.  The question is, how,
given section 3.8.3 written this way, do we know what the interoperable
cases are and what is the least that consumers and producers have to do to
ensure accomplishing that?

  - - - - - - - - - - 
  I ain't signin' no stinkin' blank checks

-----Original Message-----
From: robert_weir@us.ibm.com [mailto:robert_weir@us.ibm.com] 
<http://lists.oasis-open.org/archives/office/201005/msg00169.html>
Sent: Friday, May 07, 2010 10:47
To: office@lists.oasis-open.org
Subject: RE: [office] Do we really have that many options in ODF?

"Dennis E. Hamilton" <dennis.hamilton@acm.org> wrote on 05/07/2010 
12:55:06 PM:
<http://lists.oasis-open.org/archives/office/201005/msg00168.html>

> 
> I would say that everywhere there is a "SHOULD," "MAY,"
> "implementation-defined," and especially "implementation-dependent"
> (including when implicit in the omission of sufficient detail for it to 
be
> anything but implementation-dependent) that is PERMISSION TO CONFORMING
> PRODUCERS, we need to consider the unnatural acts and barriers that this
> imposes on consumers. 
> 

I don't think I'd say "unnatural" here.  The history of this area is quite 
clear.  There has never been an interoperable, widely-adopted, open 
standard format for office documents.  For the last 30-years it has been a 
constant state of every vendor defining their own format and than trying 
to get whatever degree of interoperability they can, via whatever means 
they could scrap together.  I think that is the  "natural" state of 
things. 

[ ... ]