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

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-comment message

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


Subject: RE: [office-comment] Re: CD01 -- 8.2.1 Referencing Table Cells


Paul (All),

[getting back on-topic]

This issue about normative text and ISO verbal provisions keeps cropping up on this list. I've given it some more thought and looked at many XML standards drafts and I think I'm going to disagree with you about how to apply the JTC 1 requirements when it comes to authoring an XML standard built around a normative schema. 

I'm assuming that a schema exists (as it does for ODF), and that the text clearly states that the provisions of the schema are normative.

That said, assume (for the sake of example) we have an element <a> for which the schema declares a REQUIRED href attribute.

Now if this was documented in ODF, my guess is the spec would say something like:

[ex 1] The <a> element represents a hyperlink. Its href attribute is used to specify a URI reference which conforms to RFC blah blah

I believe you want it to say something like:

[ex 2] The <a> element shall represent a hyperlink. Its href attribute shall specify a URI reference which conforms to RFC blah blah

Now, I actually think [ex 1] is okay, because the normative schema mandates that the attribute has to appear. In this light the narrative text is a commentary on the normative provisions of the schema. In fact, I prefer [ex 1] because it is more idiomatic (at least to me, as an English speaker) than [ex 2].

What I don't think is okay is:

[ex 3] The <a> attribute shall be used represent hyperlinks. Its href attribute can be used to specify a URI reference which conforms to RFC blah blah

As the "can be" implies optionality (which would conflict with the schema). In fact I have just written a defect report for OOXML on this very topic :-)

So, in sum, I don't believe passive voicing is necessarily a problem when it is supported by unambiguous rules expressed in a schema (but in other contexts it is, typically, not acceptable).

- Alex.


> -----Original Message-----
> From: marbux [mailto:marbux@gmail.com]
> Sent: 08 May 2009 12:42
> To: office-comment@lists.oasis-open.org
> Subject: [office-comment] Re: CD01 -- 8.2.1 Referencing Table Cells
> 
> I thank Alex for bringing the revised committee draft 02 to my
> attention.
> 
> On a closely related matter, it appears that a TC co-chair also
> believes that it is a conformity requirement in ODF 1.1 that formula
> addresses start with a "“[“ and end with a “]”.
> <http://www.robweir.com/blog/2009/05/follow-up-on-excel-2007-sp2s-
> odf.html>
> (quoting section 8.3.1; however the correction section number for the
> quoted portion is 8.1.3). The corresponding section in CD 02 is
> 17.645.
> 
> Neither ODF 1.1 nor CD 02 establish any requirements at all in regard
> to formula addresses. The relevant text is merely informative rather
> than normative. If the TC desires to create conformity requirements in
> regard to brackets and formula addresses (which would be a Very Good
> Thing), they must be worded in the imperative using "shall" or "shall
> not" as required by the authorities I cited earlier in this thread.
> 
> The closest either document comes to a conformance requirement in the
> cited sections is the statement that "[e]very formula *should* begin
> with a namespace prefix specifying the syntax and semantics used
> within the formula." However, "should" is defined by by ISO/IEC,
> ISO/IEC Directives Part 2 Annex H as only a recommendation.
> 
> Conformity may validly be claimed despite a recommendation being
> ignored. Conforming product characteristics in the international
> standards context are specified by mandatory requirements, not by
> recommendations and not by implementer interoperability plug-fests.
> Cf., the article linked above.
> 
> Best regards,
> 
> Paul E. Merrell, J.D. ("Marbux")
> 
> --
> Universal Interoperability Council
> <http:www.universal-interop-council.org>
> 
> --
> This publicly archived list offers a means to provide input to the
> OASIS Open Document Format for Office Applications (OpenDocument) TC.
> 
> In order to verify user consent to the Feedback License terms and
> to minimize spam in the list archive, subscription is required
> before posting.
> 
> Subscribe: office-comment-subscribe@lists.oasis-open.org
> Unsubscribe: office-comment-unsubscribe@lists.oasis-open.org
> List help: office-comment-help@lists.oasis-open.org
> List archive: http://lists.oasis-open.org/archives/office-comment/
> Feedback License: http://www.oasis-
> open.org/who/ipr/feedback_license.pdf
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> Committee: http://www.oasis-
> open.org/committees/tc_home.php?wg_abbrev=office



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