Re: [oic] Confirmation Flavors: #4 Legal Interop-Breaking Change

[robert_weir@us.ibm.com]

And if I write a C++ program that assumes an int is two-bytes long, it 
will not be portable to all C++ platforms.  Should we then ask C++ to 
define the length of an integer, or ask that a C++ test suite test for a 
specific value?

A reasonable taxonomy for ODF "features" are:

1) The standard mandates specific behavior
2) The standard describes a specific behavior, but does not mandate it.
3) The standard allows a choice of behaviors
4) The standard states that behavior is implementation defined
5) The standard states that the feature is prohibited
6) The standard states that the feature is undefined
7) The standard is ambiguous about a feature, not defining it fully, but 
also not giving specific allowance for implementation-defined features

For a conformance test,  we could treat failures of 1 and 5 as errors, 
failures of 2, 3 and 6 as warnings, and treat 4 as informational.

Case 7 indicates a flaw in the ODF specification, and should be referred 
to the ODF TC for fixing.  It is OK to have implementation-defined 
behaviors, but they should be explicitly called out. 

I'm reading your example as falling under 7.

-Rob

"Dennis E. Hamilton" <dennis.hamilton@acm.org> wrote on 11/14/2008 
03:49:58 PM:
> 
> Please respond to dennis.hamilton
> 
> This is a fake example that was inspired by a misunderstanding 
> between what a UI showed and what was actually in the ODF:
> 
> 1. An ODF document contains references to companion material that is
> outside of the package but is located in proximity to the package's 
> location via relative references.
> 
> 2. Processor Q accepts the document and some minor editing is done. 
> Nothing involving the links to external material is touched.
> 
> 3. When the document is saved with the changes, the links to the 
> external material have been replaced by absolute URLs to the 
> locations on the specific file system.
> 
> This breaks the interchange of the document and the companion 
> material by transfer in a Zip (or tar or other archive format) to 
> another user.
> 
> This is an interoperability situation, there being nothing in the 
> ODF specification about whether links are rewritten or not, and when
> it is important to preserve relative (or absolute) links to maximize
> interoperability and successful interchange.  The problem of link 
> adjustment when a document is moved is not a new situation and there
> is considerable practice around how to resolve links (often 
> attempting to retry with relative links when absolute ones fail).
> 
>  - Dennis
> 
> POSTSCRIPT
> 
> [The particular example I based this on did not in fact have the 
> defect I describe to illustrate this flavor.  However, a PDF 
> produced from (2) did have absolute file-system links instead of the
> relative links incorporated in the ODF document.  This reinforced 
> the assumption, based on UI behavior, that the relative URIs had 
> been rewritten to absolute ones.  Inspection of the ODF revealed 
> that they had not.  Unfortunately, the Processor Q UI made it appear
> as though links are converted to absolute, file-system-based links 
> when apparently it always manufactures relative links when it can.]
> 
> Dennis E. Hamilton
> ------------------
> NuovoDoc: Design for Document System Interoperability 
> mailto:Dennis.Hamilton@acm.org | gsm:+1-206.779.9430 
> http://NuovoDoc.com http://ODMA.info/dev/ http://nfoWorks.org 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>