OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

oiic-formation-discuss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

"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.  


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]