Re: Implementation of semantics

I agree that <semantics> is supposed to be used to annotate the first 
child and so it is weird to "annotate the annotation". However, without 
further restrictions, the first child may be any MathML element, 
including an <annotation>, so syntactically Jacques Distler's use case 
is valid although it is semantically quite different from what 
<semantics> is intended to. My main concern is to keep Gecko's 
implementation backward compatible so I'll accept this case anyway. This 
case is rather interpreted as if nothing was annotated (i.e. like SVG's 
<switch>/<foreignObject>).

**** How to choose the rendering:

It seems to me that on the Web, authors put a presentation MathML as a 
first child and use other children as alternate annotations. The 
alternate annotations are put in order of preference probably because

1) it is natural to think that the applications will process them in 
that order.
2) it is done that way for SVG's <switch>.
3) it is done that way for clipboard flavors and chapter 6 describes a 
mapping from <semantics> to clipboard flavors.

Putting the presentation MathML as a first child is probably because it 
is expected to be the one that may be rendered by browsers (preferred 
format for math on the Web and before content MathML) and is certainly 
influenced by Gecko's current implementation (renders the first child 
only, does not support content MathML). The other use case I see is 
Jacques Distler's one, where <semantics> is merely interpreted as a 
SVG's <switch>. I'm not arguing that the spec must mention that the 
children or event just the annotations should be in order of preference 
but my main concern is to handle the cases available on the Web. Just 
reading in order and stopping at the first accepted encoding seems the 
simplest implementation and works well with existing use cases. So 
that's how I'm going to implement it in Gecko.

**** Deciding if this is an embellished operator:

First, <semantics> can be compared to <maction> where the selected child 
is used to determine if it is an embellished operator. That seems the 
most obvious and easiest way for me to use the visible element. Again, 
what are the use cases on the Web? The initial bug report to implement 
embellished operator in <semantics> shows an example where the first 
child (and so visible in Gecko) was a presentation MathML that should be 
used to determine whether <semantics> is an embellished operator. I 
think it is by far the most important use case where 1) 2) and 3) 
coincide. In general, if I consider what I'm implementing in Gecko, if 
the first accepted child is a presentation MathML it will be displayed 
and used to determine if <semantics> is an embellished operator. Again, 
I think most people will put presentation MathML before any other 
alternatives so 2) and 3) coincide. 3) is the most general, but I guess 
the only use case would be <semantic> (content MathML) (presentation 
MathML) (other annotations) </semantics> and since Gecko does not render 
content MathML it will render presentation MathML. Probably, if a more 
general selection than child order is implemented in Gecko, it would be 
to render presentation MathML first and so 2) and 3) will coincide again.

As a conclusion, from the existing use cases on the Web, I don't think 
it is worth trying to implement another selection method for <semantics> 
than child order. And I don't think it is worth trying to pick 
embellished data from another presentation MathML element after the 
selected child (or if we know there is such an element, Gecko would just 
use it as the visible child). So unless there is a strong demand from 
users, I'll keep the implementation I'm currently working on which 
sounds the simplest one. I don't mind if option 3) is added to the spec 
for embellished operator selection as in practice I think it will just 
be like 2). Please add the fact that <annotation-xml> should behave the 
same as <mrow> with respect to embellished operator, if it is not 
already the case, so that embellished op data can be passed to the 
parent <semantics>.

Thanks.

On 01/11/2012 23:26, Neil Soiffer wrote:
> <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 <http://www.dessci.com>
> ~ Makers of MathType, MathFlow, MathPlayer, MathDaisy, Equation Editor ~
>
>


-- 
Frédéric Wang
maths-informatique-jeux.com/blog/frederic