resolution of last call issues

Hi Simon,

The actions we have taken on the issues you raised for the Last Call
on MathML 2.0 2nd Edition are detailed below.  Thanks for all the
close reading of the text and DTD.  The specification has benefitted
greatly. 

To assist us in preparing a Last Call report, we would appreciate it
if you could post a brief message acknowledging we have responded to
the points you've raised. 

========================
Comments and Resolutions
========================

> In section 3.3.4.2 color is listed as an attribute of mstyle. Because
> it is an attribute of all token elements, it need not be listed here.

Removed.

> The example in section 3.5.5.8 has an error: The groupalign attribute
> should be a list of lists, i.e., it should be enclosed in braces.

Fixed.

> If I interpret the spec on alignments correctly, it is not possible to
> skip an alignment group in a group-alignment list. Then, if a
> malignmark is used in some alignment group, it probably has priority
> over the value listed for this alignment group in the group-alignment
> list. I did not find a reference to this case in the spec; it might be
> useful to add a description.
> 
> An example that illustrates the point: [snip]

Section "3.5.5.7 Inheritance of groupalign values" does actually
address this.  However, I added a sentence giving this specific case
as an example of the general rule.

> In a recent discussion with publishing colleagues the following
> question came up: What is the meaning of 
> 
> <mi mathvariant="bold">&#x1D538;</mi>
> 
> Is it at all allowed? If the answer is clear, then maybe the
> explanation in the spec should be expanded to include it. Or is it
> not possible to give a definite answer in the current version of
> MathML? 
>
> [we had a couple more exchanges in this thread as well]

I rewrote the text of 3.2.1.1 and 3.2.2 to make this clearer.  It used
to say that when the mathvariant attribute was applied to character
data outside the ranges defined in chapter 6 (the plane 1 alphanumeric
characters) where there is a clear BMP+mathvariant/SMP correspondence,
it was up to the renderer to decide what happens  (so don't do it).  Now
it says that we suggest renderers ignore the mathvariant attribute in
these cases (so don't do it).

---------------------------------

Once again, thanks for your comments.

--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 14:57:33 UTC