From: Murray Sargent <murrays@exchange.microsoft.com>

Date: Wed, 3 Dec 2014 22:29:13 +0000

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

CC: William F Hammond <hammond@csc.albany.edu>

Message-ID: <586abcfc5f4544e7bba377b7f15b43fb@DFM-TK5MBX15-06.exchange.corp.microsoft.com>

Date: Wed, 3 Dec 2014 22:29:13 +0000

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

CC: William F Hammond <hammond@csc.albany.edu>

Message-ID: <586abcfc5f4544e7bba377b7f15b43fb@DFM-TK5MBX15-06.exchange.corp.microsoft.com>

Re <mfenced> I think it should be kept and I'd prefer if <mnary> were used instead of the pot pourri <msup>, <msub>, <msubsup>, <mover>, <munder>, <munderover> for n-ary expressions. In OMML, there's <d> (essentially <mfenced>) for delimited objects (parenthetical/bracketed expressions) and there's <nary> for n-ary expressions. <nary> has three arguments: two limits and a n_aryand, whereas the pot pourri tags don't identify the n-aryand. OMML is an XML where you know from the opening tag what the object is, whereas Presentation MathML needs sophisticated parsing much along the lines needed for the Unicode plain text encoding of mathematics (http://www.unicode.org/notes/tn28/UTN28-PlainTextMath-v3.pdf). In fact, the Microsoft Office MathML parser uses the rich-text string stack originally developed for building up plain-text math content. The main math layout ideas are documented in The TeXbook in Appendix G. In particular, you have objects with arguments and you measure the arguments (recursively) and place them along with lines, etc. as needed for the objects. A delimiter object is handy since you measure its contents and then display the result with brackets that fit (according to special rules). The inline approach seems more complicated to me. At least it requires a different approach from objects such as <menclose>. For the same reason, I prefer <mfract> to <mrow>...<mo>/</mo>...</mrow>. We use nontrivial code to convert the inline versions to the prefix versions. In any event, this is all water over the dam. Deprecating any Presentation MathML tags would break too many implementations. MurrayReceived on Wednesday, 3 December 2014 22:29:49 UTC

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