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


Help: OASIS Mailing Lists Help | MarkMail Help

office message

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

Subject: RE: [office] Re: [office-formula] BITAND - Normative Statements


I was objecting to the use of "shall" where the conformance target (as
identified in a conformance section) is not clearly-established.  It was in
that sense that I didn't find either statement acceptable.

With regard to your observations about ODF 1.2 Part 1, there may indeed be
many places where the use (or absence) of normative terms needs to be
cleaned up.  I have nothing to say with regard to the weight that should be
given in voting on approval of CD03 rev07 as CD04 for Public Review. 

 - Dennis



   1.1 There are defined conformance targets established in subsections
21.2-21.4 of Section 21 Document Processing and Conformance of ODF 1.2 Part
1 cd03 rev07 now under ballot for approval as cd04 and submission as a
Public Review Draft.

   1.2 It seems to me that normative statements are required to use the
normative terms declared in ODF 1.2 Part 1 Section 1.2 (i.e., shall, shall
not, should, should not, may, need not, [and can, and cannot though those
are not explicitly cited]).  As I recall, [ISO/IEC Directives] is quite
rigorous about how such terms are to be used without variation.

   1.3 When that terminology is not used or is used in ways not intended, we
should indeed clarify those statements.

   1.4 Furthermore, if a statement expresses a normative condition, my
understanding is that it is essential to identify the specific conformance
target(s) as defined in the Conformance section.  


   2.1 For example, it might be appropriate to say, in Part 1, section
19.644 "For a Conforming OpenDocument Spreadsheet Document, the length of a
table:formula attribute string value shall not exceed 4096 characters,
excluding any prefix and after processing of character entities and white
space."  (Other string datatype characteristics are determined by the XML
Schema specification, including what the length is a length of, and I don't
know if it is necessary to be any more specific in ODF 1.2.  In any case I
am not proposing this statement, just illustrating the way normative
statements are tied to conformance targets.)

   2.2 Technically, one might want to say what the target is for the section
19.644 sentence beginning "The attribute value should begin with a namespace
prefix ... ."  
   One way to deal with this would be to make a descriptive statement that a
table:formula attribute value begins with an optional combination of a
namespace prefix and following ":", eliminating the normative-seeming
occurrence of "should" there.  
   One might then follow that with something that is specific about the
target the "should" was meant to apply to, such as "Conforming OpenDocument
Producers should provide the prefixed-form of table:formula attribute
   It might also be appropriate to assert that when present the prefix shall
be namepace well-formed and, just to be safe, be restricted to the syntactic
form of an NCName, since [xml-names] doesn't cover this use of a namespace
prefix at the beginning of an attribute value.

   2.3 [Speculations: I don't know what we should do to prevent formulas
from having constructs where the beginning might be syntactically
indistinguishable from an NCName followed by a ":".  I suppose, in that
case, a prefix form would have to be used to prevent the formula itself from
being taken as the prefixed form and either passing or failing namespace
well-formedness.  I think its sufficient, then, to state that edge case as a
"shall" condition on the producer, with the should applying otherwise.  Or
we could just let the default understanding of an OpenFormula formula (so
long as always beginning with at least one "=") handle the situation.]


   3.1 We've been working on tightening of the conformance language since
this time in 2008.  I am not sure what the accountability is for detailed
review of the Part 1 text and ensuring that normative terms appear only in
normative statements and the connection with the conformance targets is

   3.2 I presume that it is appropriate to submit JIRA issues with proposals
for clean-up of specific instances, and that could certainly happen
concurrent with a public review (and the public might have something to say
about it too).

   3.3 I have no opinion on whether or not Approval of Part 1 cd03 rev07 as
cd04 for Public Review should hinge on the normative terminology being
cleaned up first.

   3.4 However, I do think it would be a shame to achieve Committee
Specification status without appropriate detail work on the conformance
language and normative statements having been carried out.  That's my own
considered opinion. 

-----Original Message-----
From: Andreas J Guelzow [mailto:aguelzow@math.concordia.ab.ca] 
Sent: Thursday, December 10, 2009 17:37
To: office@lists.oasis-open.org
Subject: RE: [office] Re: [office-formula] BITAND - Normative Statements

Hi Dennis,

On Thu, 2009-12-10 at 16:09 -0800, Dennis E. Hamilton wrote:
> I believe I answered the question that I was asked by Andreas with
> sufficient rationale (and supporting material) to explain the basis for
> answer.  (Whether that is necessary rationale, I don't know, but I am not
> sure how much we are all up to speed on the procedures and the conformance
> guidelines that figure in them.)

In the "PS" you had referred to I had suggested deleting "To comply with
this specification," which you objected to. So I asked:

> > could you explain to me what you see as the difference between the
> > following two statements (in the context of the OpenFormula
> > specification):
> >
> > 1) To comply with this specification, an implementation *shall* support
> > parameters of at least 48 bits.
> >
> > 2) An implementation *shall* support parameters of at least 48 bits.

It seems to me that your "answer" was that you didn't think either was
correct. I still don't know why we have that prefix "To comply with this
specification,". Or how this sentence could be formulated in a way that
you find acceptable.

It appears that you object to the subject of that sentence. I note the
use of "ODF editing implementations", "Implementations can"...,
"Implementations need not"..., ..."used by implementations that"...,
"Implementations may"..., "implementations should"..., "implementation
shall"... in the current committee draft of part 1. If any of these
expressions is truly a problem, I gather one should vote against sending
the draft to public review.


Andreas J. Guelzow
Concordia University College of Alberta

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