Re: [oiic-formation-discuss] Deliverable: odf-diff?

[robert_weir@us.ibm.com]

"Dave Pawson" <dave.pawson@gmail.com>
wrote on 06/23/2008 10:14:04 AM:

> 2008/6/23  <robert_weir@us.ibm.com>:
> 
> > Whether something is testable or not does not depend on whether
it is a
> > "shall" or a "should".  Both are provisions
of the standard, and both are
> > normative.  "Shall" denotes a requirement and
"should" denotes a
> > recommendation.  Whether it is testable or not depends on
whether the
> > provision is written precisely, accurately and clearly.  In
particular, we
> > could define the test requirements such that violations of requirements
and
> > recommendations are both reported, perhaps with different output
classes,
> > e.g., "error" versus "warning" versus "informational".
> 
> Heavy request Rob.
> 
> IF this is definitive, would you expand your thoughts.
> 1. Interpretation as used in the current standard (shall ....)
> 2. What you expect of the various classes of statement
> found in the spec.
>   Hard ones(clear, shall): test it, fail the test= fail the overall
run etc.
>   fluffy (may, clear): test it, fail= warning
> 
> etc.

OASIS ODF 1.0 uses the control vocabulary according
to IETF RFC 2119 (http://www.ietf.org/rfc/rfc2119.txt)

OASIS ODF 1.0 (second edition), ISO/IEC 26300, OASIS
ODF 1.1 and OASIS ODF 1.2 use the definitions given by ISO Directives,
Part 2, Annex H: http://www.iec.ch/tiss/iec/Directives-Part2-Ed5.pdf

I think we are saying that we want to concentrate
on the current ODF version, which is now ODF 1.1, so the ISO definitions
are the only ones that are relevant.  

From a conformance checking standpoint, I believe
we would check only what ISO calls "requirements" and "recommendations".
 These include the "shall" and "should" statements,
as we've discussed, but there are also equivalent formulations that are
allowed and listed in ISO Directives, Part 2, Annex H.  We could certainly
call these two classes "error" and "warning".  The
binary pass/fail conformance question would be defined as not generating
any error.

I think additionally that we could define an interoperability/portability
tester that could introduce a third class of message, which we might call
"note".  This would be to report items which we (the proposed
OIIC) TC believes has an adverse impact on interoperability, but for which
the ODF standard expresses neither a requirement nor a recommendation.
 

Think of it this way -- the C/C++ standards define
what is allowed or not allowed.  But these standards don't legislate
good taste or good engineering practices.  But others have come along,
with style guidelines, tools like "lint" and so on which have
given users of these standards the ability to extract greater value from
these standards by testing their programs against a stricter set of constraints.

One practical example that we've discovered is that
spreadsheet sheet names are defined as an xsd:string in ODF.  This
XML Schema type has no preset length limitations.  However, we've
found that Excel will issue an error message when loading documents with
sheet names that exceed 31 characters in length.  

What do we do about items like this:

1) Do nothing, since the ODF standard states no upper
limit on length. (Doesn't solve the problem.  In practice, interoperability
problems are made of stuff like this.  We need to tackle this if we're
to have a practical impact.)
2) Define a new profile for portable spreadsheets
that sets upper length as 31 characters? (We could do that certainly, but
a new profile could take over a year)
3) Report it as a defect to Microsoft and wait for
it to be fixed (Will never happen)
4) Change the conformance clause of ODF to make round
trip interoperability mandatory under pain of imprisonment and torture
(Sounds great, but doesn't accomplish anything)
5) Add a test case to an interoperability test suite
that issues an informational note whenever a sheet name exceeds 31 characters.
 (Allows implementations to improve interoperability now, if they
want to).

The interoperability tests are stricter than the conformance
tests.  They never contradict the ODF standard.  A practical
way in which this would all help improve interoperability, would be if
applications, when reading ODF, were able to read everything that the ODF
standard allows, but when writing ODF, they should write conservatively,
and aim to have their output documents issue no errors (of course) but
also no warnings or notes.  

-Rob