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

QA WG comments on the spec

From: Robert Miner <RobertM@dessci.com>
Date: Tue, 17 Jun 2003 14:53:03 -0500
Message-Id: <200306171953.h5HJr3r11199@wisdom.geomtech.com>
To: lofton@rockynet.com
CC: www-math@w3.org


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 Tuesday, 17 June 2003 15:53:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 20 February 2010 06:12:55 GMT