Re: Implementation of semantics

<snip>

>
> 2.  Despite what the schema may say (another fix needed?), the first
child can be annotation/annotation-xml in addition to "raw" MathML. That
annotation can be presentation MathML, SVG, or XHTML.  You might want to
use the order to determine the top pick. I don't recall if we discussed
using ordering for a preference in the MathML WG.  If we did, it didn't
make it into the spec.


</snip>

I blew it on that statement.  The MathML3 spec is silent on it and
MathPlayer does it that way (I didn't do that part of the implementation),
but the MathML2 spec in 4.2.6 said "semantics expects a variable number of
child elements. The first is the element (which may itself be a complex
element structure) for which this additional semantic information is being
defined. The second and subsequent children, if any, are instances of the
elements annotation and/or annotation-xml"

So the first child should not be annotation or annotation-xml.  That didn't
get carried forward into the MathML 3 spec, but apparently got omitted in
the big shuffle for that part of the spec. I think this requirement for the
first element causes problems with Jacques Distler's test case though...

That leaves (I think) two remaining issues:

How to choose the rendering:
The spec doesn't seem to provide a way for authors to communicate with
renders rendering preferences.  Speaking for myself, I don't see a way of
dealing with that as a clarification or errata as I think it will require
adding an attribute -- the ordering can't be used since the first child
must be presentation or content MathML, and since that can be rendered by a
MathML renderer, you don't know whether to use that or some other one (such
as SVG) as a better representation for what is intended.

Deciding if this is an embellished operator:
There are three cases that are reasonable:
1.  Use the first child
2.  Use the rendered child
3.  Use presentation MathML if it is present, otherwise it isn't an operator

For '1', the first child can be content MathML.  The renderer may or may
not be able to render the content as MathML.  So using the first child
choice might have problems as some renders might resolve it to an mo and
others not.

For '2', again, this is implementation dependent, so the spacing isn't
guaranteed. For an image or SVG, this raises the question of whether it
should or should not incorporate left/right spacing to accommodate its
surroundings.

For '3', the problem occurs if there is no presentation MathML given.
 Perhaps the answer is that in that case, it should not be considered an
operator. Speaking for myself, I like '3' as the best alternative because
results in a consistent interpretation.

In earlier email, Frédéric wrote that he prefers '2':
====
Regarding my fourth question, I think it does not really make sense
either to take the presentation MathML to determine whether it is an
embellished operator, when this element is not visible. At least in
Gecko, the embellished operator data passed to the parent also contain
who should be stretched, so it's really relevant only if it is the
operator is visible.
====

That argument is based on the implementation in Gecko -- other
implementations may differ.  '2' means that one can't specify that the
semantics element should be interpreted as an embellished operator that
behaves in a given way (as defined by some presentation MathML/mo element).

Neil Soiffer
Senior Scientist
Design Science, Inc.
www.dessci.com
~ Makers of MathType, MathFlow, MathPlayer, MathDaisy, Equation Editor ~