Re: Comments for PR-MathML2-20010108

Hi.

I'm commenting on this separately, since it provoked some discussion.

> Two small structural changes are needed. First, a conformance chapter
> should be evident from the front table of contents. I would break
> out the relevant parts of section 7.2.1 into a separate page
> called "Conformance." Second, Appendix K needs a normative section.

I am reorganizing 7.2 to put Conformance in the TOC.  However, the WG
isn't comfortable making Appendix K normative.  There were some issues
with doing that.  David has the details if you want them.

> Especially to help the conformance chapter, and also to be clear,
> you could make RFC 2119 a normative reference and quote this part:
>        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
>        NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
>        "OPTIONAL" in this document are to be interpreted as described in
>        RFC 2119.
> Please see RFC 2119 at http://www.ietf.org/rfc/rfc2119.txt. If you don't
> wish to use this RFC, then these words need definitions. If you don't
> like the RFC-style caps, then here is an alternate idea:
> <p>The key words <strong>must,</strong> <strong>must not</strong>,
> <strong>required</strong>, <strong>shall</strong>, <strong>shall
> not</strong>, <strong>should</strong>, <strong>should not</strong>,
> <strong>recommended</strong>, <strong>may</strong>, and
> <strong>optional</strong> in this document are to be interpreted as
> described in [<a href="appendixk.html#RFC2119">RFC2119</a>].</p>

Although I completely agree that is would help, we don't think we can
do this either.  We are suffering for being an old group.  Since we
have long had this conformance language, it is a somewhat entrenched.
Changing it might cause problems for companies who now claim to be
compliant, and that might be in jeopardy with more stringent
language. We just can't do that without review at the end of PR.

However, we do have a separate Compliance Document on the site, so I
will add a reference to that, so a stricter conformance policy can be
added in the future.

--Robert

------------------------------------------------------------------
Robert Miner                                    RobertM@dessci.com
MathML 2.0 Specification Co-editor                    651-223-2883
Design Science, Inc.   "How Science Communicates"   www.dessci.com
------------------------------------------------------------------

Received on Tuesday, 30 January 2001 22:31:58 UTC