RE: [oic] Confirmation Flavor: #3 Incorrectly-Generated ODF

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

Great observations.  Let's look a little closer.

"Cannot happen" is a little strong.  This reflects a real situation
uncovered in some interoperability exercises.  There are documents in the
wild for which a Processor Y behaves as described.

Now, it may be that the implementers of Processor Y and the implementers of
Processor X disagree about how the specification is understood.

But the key thing is that documents that claim to be ODF 1.1 having such an
alleged defect already exist and we have no idea which ones they are.

Suppose that the way the implementer of Processor Z chooses to deal with
this is to assume that the document is incorrect but that it is easy to
correct for this known behavior by accepting X's document and silently
substituting an ODF construction that all implementers agree is correct and
that is accepted just fine by Processors X, Y, and Z. 

In fact, let's suppose the implementers of Processor Y come to the oic-user
list and ask for guidance on what they should do with this case, since they
can	also change Processor Y to do what processor Z does.  This is a bona
fide pragmatic interoperability situation.  What should our advice be?
(Remember, the users of Processor X are busily churning out and circulating
documents and some of them will have this defect, if that is what it is.)

 - Dennis

-----Original Message-----
From: Andreas J Guelzow [mailto:aguelzow@math.concordia.ab.ca] 
http://lists.oasis-open.org/archives/oic/200811/msg00021.html
Sent: Thursday, November 13, 2008 19:47
To: oic@lists.oasis-open.org
Subject: Re: [oic] Confirmation Flavor: #3 Incorrectly-Generated ODF

On Thu, 2008-11-13 at 18:36 -0800, Dennis E. Hamilton wrote:
http://lists.oasis-open.org/archives/oic/200811/msg00018.html
> Here's a case that it is hard to imagine creating a test for.
> 
> #3 INCORRECTLY-GENERATED ODF 
> 
> Under certain conditions, processor X produces an ODF 1.1 .odt file
> where the content.xml and styles.xml documents are valid according to
> the schema, but a constraint stated in the specification is
> violated.  

But this cannot happen. If a constraint is violated then the created
file is not an ODF 1.1 file, but just a file the processor X falsely
claims to be ODF 1.1.
> 
> Processor Y fails to load the document, reporting an error in the
> content.xml file.
> 
> Processor Z loads the document and processes it as correct.  When the
> document is saved, the resulting content.xml does not violate the
> constraint of the specification.
> 
> Because this is a negative condition (the specification is violated),
> there is no specified behavior for it in the ODF specification.  The
> document is, technically, not conforming in any respect.
> 
> On the other hand, one might consider that Processor Z behavior is
> superior to Processor Y's.

Processor Ys and Zs behaviour here has nothing to do with ODF: they are
acting differently on some strange file. Whether you consider one
behaviour superior to another depends only on your expectations in the
given circumstances.

[ ... ]