RE: [office-comment] ODF 1.2 References

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

Paul, 

That textual examination of the use of terms found in conformance language is very useful.

I want to point out that, for the ISO/IEC nomenclature, MAY and NEED NOT go together and MAY NOT (as a prohibition) is not acceptable normative language.  

Also, I think sometimes the use of MAY and MAY NOT is more in the sense of CAN and CAN NOT (with regard to possibility, as opposed to permission or prohibition).  

I have also noted that SHOULD in the ISO/IEC sense is quite different, and considerably weaker as a prescription, from the SHOULD as used in the IETF sense. 

(You will notice how I indicate bold face in plaintext, which is probably the same reason that the IETF uses capitalization, since the authoritative texts of IETF RFCs are in plaintext.)

I also agree that the use of those terms in anything but their conformance-language sense is a problem, with the safest solution being to refrain from use of those terms in any other way, capitalized, enboldened, or not.  (I also assume that technical use of a style in the formatting of the ODF version is not that helpful for the PDF version of the document.)

On the other hand, one potential assist in the clarification of when normative terms are being used is from the OASIS guidelines for conformance sections and conformance language.  There, there is a notion that every statement that has conformance language in it is distinguished in some way (the W3C does this, for example), there is some form of index or compilation of all of them, and each of them can be traced to a conformance target specified in the Conformance section of the specification.

I am not clear what the alignment of the ODF TC is with respect to those guidelines, however, and this discussion might lead us to consider the guidelines more explicitly.

 - Dennis

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 




-----Original Message-----
From: marbux [mailto:marbux@gmail.com] 
Sent: Monday, February 23, 2009 07:36
To: MURATA Makoto (FAMILY Given)
Cc: office-comment@lists.oasis-open.org
Subject: Re: [office-comment] ODF 1.2 References

On Sun, Feb 22, 2009 at 5:46 AM, MURATA Makoto (FAMILY Given)
<eb2m-mrt@asahi-net.or.jp> wrote:
> First, I believe that ODF 1.2 cannot become an ISO/IEC standard unless it
> ALWAYS uses "shall" or "should" as specified in Annex H of [ISO/IEC
> Directives].  If "shall" or "should" is used incorrectly, I believe
> there will be comments from member bodies and comments from ITTF.
> Comments from ITTF cannot be turned down.  Thus, the sentence you
> quoted cannot appear in the next edition of ISO/IEC 26300, I believe.

The committee draft has issues in this area, although I note that
ISO/IEC:26300-2006 has even more. Some WordPerfect word counts (not
yet confirmed by a second run on a different word processor):

Frequency of keyword terms indicative of options and recommendations:

may 3,490
*may not 19
*optional 26
should 295
should not 12

Total 3842

Frequency of keyword terms indicative of mandatory requirements:

*must 207
*must not 13
shall 80
shall not 22

Total 322

Further caveat: this is for the entire committee draft including
informational portions.

The terms marked with an asterisk above other than "may not" are
apparently leftovers from OASIS ODF 1.0, which used the RFC 2119
requirement keyword definitions. Their occurrences should be replaced
with their ISO/IEC equivalents.

"May not" might pass muster when viewed in isolation because "may" is
a defined term in the ISO/IEC Directives Part 2 Annex H. But when you
skim the passages that use the term in the committee draft, the term
seems sometimes intended to express permission, in others a
prohibition, and in still others it is not clear to me which sense was
intended.

But bottom line, it looks like there's some editorial work to do on this issue.

[ ... ]

On a closely related matter, the committee draft's section 1.2 states
that the requirement keywords only acquire the meanings given by
ISO/IEC Directives when set in bold face. This is problematic in
several different ways.

1. What meaning do those terms have when not set in bold face? By
implication their meanings may differ in that circumstance. But how
they differ in that context is unspecified.

2. This is no small problem by historical measure. All previous
published versions of ODF include many instances of requirement
keywords that should have been set in bold face but were not.

3. The reliance on bold face (or other text attributes) as an
indicator of requirements can neither be sent as plain text email or
easily be converted to plain text email without manual revision of
emphasized strings or loss of data as to what is and is not a
requirement keyword. I strongly suspect this is the reason that nearly
all IT standards I've looked at use all-capitalized characters for
requirement keywords rather than bold face or some other text
attribute.

4. I raise the question of whether there is any remaining need to
distinguish between relevant terms as to when the ISO/IEC definitions
apply. However, I caveat that I do not know the answer to that
question. But there are indications that there may not be such a need.

[ ... ]

If there in fact remains no reason for distinguishing between
circumstances when the terms take the ISO/IEC definitions and when
they do not, then the word processor's global find and replace feature
can be used by the editor to provide whatever emphasis is desired, if
any, for the terms in the text. It might be that only the usage of the
"shall" and "shall not" terms might need checking in context to ensure
that they are not in informational portions of the specification.

5. If the convention is preserved of distinguishing between
circumstances when the terms take the ISO/IEC definitions and when
they do not, the meaning of those terms when they are not emphasized
should be defined.

6. The present committee draft does not yet have the majority of
requirement keywords in the text marked in any way. Whatever
resolution is made of the issues above, at least one committee draft
should be produced that has the the full text emphasized as envisioned
for review by TC members prior to the public review version.

[ ... ]