From: Neil Soiffer <NeilS@dessci.com>

Date: Thu, 1 Nov 2012 15:26:54 -0700

Message-ID: <CAESRWkCBGTX7K+y=yhMXaQ6St_UahdfQ-_Ea-pTnUYML8DV3qw@mail.gmail.com>

To: Neil Soiffer <NeilS@dessci.com>

Cc: Frédéric WANG <fred.wang@free.fr>, "www-math@w3.org" <www-math@w3.org>

Date: Thu, 1 Nov 2012 15:26:54 -0700

Message-ID: <CAESRWkCBGTX7K+y=yhMXaQ6St_UahdfQ-_Ea-pTnUYML8DV3qw@mail.gmail.com>

To: Neil Soiffer <NeilS@dessci.com>

Cc: Frédéric WANG <fred.wang@free.fr>, "www-math@w3.org" <www-math@w3.org>

<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 ~Received on Thursday, 1 November 2012 22:27:23 UTC

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