W3C home > Mailing lists > Public > www-qa-wg@w3.org > June 2003

Re: QA WG comments on the spec

From: Lofton Henderson <lofton@rockynet.com>
Date: Tue, 24 Jun 2003 09:04:40 -0600
Message-Id: <5.1.0.14.2.20030624083656.061aa290@rockynet.com>
To: Robert Miner <RobertM@dessci.com>
Cc: www-math@w3.org, www-qa-wg@w3.org

Hello,

The QA WG acknowledges your reply to our comments on your Last Call 
document of MathML Second Edition.

At yesterday's (20030623) teleconference, QA WG agreed that we approve of 
and accept your responses.

Thanks for taking the time to consider and respond to the QA WG comments.

Regards,
Lofton Henderson
(QA WG co-chair)

MathML response to QAWG, 1 of 2:
----------

At 02:53 PM 6/17/03 -0500, Robert Miner wrote:

>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
>------------------------------------------------------------------

MathML response to QAWG, 2 of 2:
----------

At 02:57 PM 6/17/03 -0500, Robert Miner wrote:

>Hi.
>
>Oops.  I just saw
>
> > The spec. uses the term 'conformance' whereas the linked guidelines
> > document uses the term 'compliance' even though the content of the
> > guidelines document is essentially the same as the spec. If there are
> > to be separate documents covering conformance/compliance it is
> > recommended they use a single term. QAWG prefers 'conformance'
>
>We had changed the "conformance" to "compliance", but I will now
>switch them all back to conformance.
>
>--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 Tuesday, 24 June 2003 11:04:44 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.30 : Thursday, 9 June 2005 12:13:14 GMT