From: Frédéric WANG <fred.wang@free.fr>

Date: Sun, 04 Nov 2012 13:54:45 +0100

Message-ID: <50966595.1050107@free.fr>

To: www-math@w3.org

Date: Sun, 04 Nov 2012 13:54:45 +0100

Message-ID: <50966595.1050107@free.fr>

To: www-math@w3.org

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/fredericReceived on Sunday, 4 November 2012 12:53:07 UTC

*
This archive was generated by hypermail 2.3.1
: Tuesday, 6 January 2015 21:27:45 UTC
*