Fwd: QA WG comments on the spec [MathML]

QAWG, fyi -- MathML reply to our comments (prepared by Andrew).

In telecon (Monday) let's affirm that they have made a reply and that we're 
happy with it.  I.e., if anyone is unhappy with it, now is the time to object.

Therefore before please look at their response, and if you have any 
problems or objections to it, raise them Monday.

-Lofton.

>Date: Tue, 17 Jun 2003 14:53:03 -0500
>From: Robert Miner <RobertM@dessci.com>
>To: lofton@rockynet.com
>Cc: www-math@w3.org
>Subject:  QA WG comments on the spec
>X-RCPT-TO: <lofton@rockynet.com>
>
>
>Hi.
>
>Below I've detailed the resolution of the issues the QA WG raised
>during the Last Call for MathML 2.0, 2nd Edition.  Thanks for your
>carefull reading of the spec, and your comments.
>
>To help us put together our last call report, we would appreciate it
>if you could post a brief message acknowledging we've responded to
>your comments.
>
>=========================
>Comments and Resolution
>=========================
>
>This is the back matter from the review you posted at
><http://www.w3.org/QA/WG/2003/05/SpecGL-MathML20-review.html>.
>
>
> > Generally the specification conforms well to SpecGL.
> >
> > The main weakness is lack of information about the conformace
> > implications of extensions to the spec. The possibility of extensions
> > is readily acknowledged and in the main case a mechanism is provided
> > but it is noted that there are interoperability issues here which are
> > not dealt with other than to dissuade an implementer from using the
> > extension mechanism where possible.
>
>We've added a new section "7.2.1.3 MathML 2.0 Extension Mechanisms and
>Compliance"  It ennumerates the three extension mechanisms that MathML
>2.0 sanctions -- mglyph, namespaced attributes for maction, and
>definitionURL in content markup.
>
>We then describe how abuse and/or future standards activity might lead
>to contradiction with the spec, or at least undesirable consequences.
>
>Finally, there is a paragraph cautioning implementor and maintainers
>of documents to be aware of the issue, and monitor relevant
>conventions and standards activity.
>
> > The spec. does not use strong, prescriptive RFC2119 language and this
> > makes it harder to locate assertions (but easier to read...). Specific
> > requirements are not tagged (to allow linkage to tests) although there
> > is a test suite (which I haven't looked at)
>
>We dicussed using RFC2119 language, but in the end concluded not to do
>it.  The reasoning was that if we limited its use to the section on
>compliance in chapter 7 it wouldn't be much use, since there are lots
>and lots of assertions throughout the text that should then also be
>stated in those terms.  On the other hand, making all those changes
>would have a very significant impact on the spec, and we weren't at
>all confident we could do it without introducing new and non-obvious
>problems.
>
> > I was a little confused about product classification. There is more
> > than one classification scheme for the same set of applicable
> > products. Conformance product classes and discretionary implementation
> > classes use different terms.
>
>We added a few sentences in chapter 7 about product categories.
>
> > There is a separate document for "Compliance Guidelines". This
> > document appears to duplicate material in the conformance section of
> > the specification which raises document maintenance concerns. Also
> > both 'compliance' and 'conformance' are used (to mean the same
> > thing).
>
>For the 2nd Edition, our thought was to update this the Guidelines to
>serve more as a guide to current activity, e.g. new validation tools,
>interoperability tests, etc.  Clearly it should not just regurgitate
>the spec, as it currently does.
>
>Also, we changes 'conformance' to 'compliance' in the three places it
>appears in the spec.
>
>
>--Robert
>
>------------------------------------------------------------------
>Dr. 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 Wednesday, 18 June 2003 02:51:15 UTC