From: Robert Miner <robertm@dessci.com>

Date: Thu, 30 Mar 2006 15:55:01 -0800

Message-ID: <D1EFB337111B674B8F1BE155B01C6DD6190880@franklin.corp.dessci>

To: "Bruce Miller" <bruce.miller@nist.gov>, <www-math@w3.org>

Cc: "Public MathML mailing list" <www-math@w3.org>

Date: Thu, 30 Mar 2006 15:55:01 -0800

Message-ID: <D1EFB337111B674B8F1BE155B01C6DD6190880@franklin.corp.dessci>

To: "Bruce Miller" <bruce.miller@nist.gov>, <www-math@w3.org>

Cc: "Public MathML mailing list" <www-math@w3.org>

Hi. Sorry to come late to this thread, but I wanted to chime in here. You wrote: > To get back to Paul's original question; Have you thought of > taking a hybrid approach? Ie. expand the selection based > on presentation-tree considerations, and then _if_ there are > parallel markup linkages, adjust the selection as needed. > That would seem to do as much fixup as you can, given whatever > markup you're given. This is basically what we do in WebEQ and MathFlow. The selection works on the p-mathml tree, allowing one to do text-style selection. But at nodes where there is a parallel c-mathml tree, you return that. So if you have <mrow> <mi>a</mi> <mo>*</mo> <mi>b</mi> <mo>+</mo> <mi>c</c> </morw> and select a * you get back <mi>a</mi> <mo>*</mo>. However if you select a * b you get back <apply><times/><mi>a</mi><mi>b</mi> --Robert Dr. Robert Miner Director of New Product Development - our address has changed- Design Science, Inc. 140 Pine Avenue, 4th Floor Long Beach, California 90802 USA Main: (562) 432-2920 Direct: (651) 223-2883 Fax: (651) 292-0014 robertm@dessci.com www.dessci.com -----Original Message----- From: www-math-request@w3.org on behalf of Bruce Miller Sent: Thu 3/30/2006 8:14 AM To: www-math@w3.org Cc: Public MathML mailing list Subject: Re: Mathematical selection Richard Kaye wrote: > On Thursday 30 March 2006 12:35, Paul Libbrecht wrote: > >>W Naylor wrote: >> >>>I though to try out the ORCCA tex -> MathML translator on your >>>example:I input the document: >>>\documentclass[11pt]{article} >>>\begin{document} $$3*a+b$$ \end{document} >>>and get out the MathML: >>><math xmlns="http://www.w3.org/1998/Math/MathML" display="block" >>>overflow="scroll"> >>><mn>3</mn><mo>*</mo><mi>a</mi><mo>+</mo><mi>b</mi></math> >>>now this is machine generated, (though I suspect that many authors would >>>be lazy and wouldn't put an mrow around the 3*a, if they were creating >>>this by hand) >> >>Well, that's an example where solution-1 >>(presentation-tree-based-selection) is doing the same as text >>selection... it clearly is wrong but if the author is aware of it, he > > > Actually, it is only clearly wrong with standard semantics where > + = addition and * = multiplication on some standard field such > as the real numbers, and using standard conventions on precedence > (and perhaps in a context where you are using standard classical > logic to discuss real numbers). I'd argue it's wrong in any case, or at least of dubious meaning; What does a construct like "a op1 b op2 c" mean?. It's just that the "right" form is not apriori clear, without knowing the author's intended notations. And if you're opening the can'o'worms of non-standard notations, why assume that * and + are infix operators at all? Maybe "3*" is a prefix opererator acting on "a" ? By default TeX assumes they are operators, but, like MathML, there's no precedence associated with them. Unless the author's markup is has explicit structure, whatever agent is translating to MathML will need to parse. Ideally that agent would allow for non-standard notations, but the standard makes a good default. To get back to Paul's original question; Have you thought of taking a hybrid approach? Ie. expand the selection based on presentation-tree considerations, and then _if_ there are parallel markup linkages, adjust the selection as needed. That would seem to do as much fixup as you can, given whatever markup you're given. Depending on what the selection is _for_, however, a pure single content subtree might not be what's desired, however. It might be reasonable to select multiple subtrees provided they are adjacent siblings. Assuming the above example were properly nested (using standard precedence :> ), "*a" (two subtrees) might be a useful selection that would fit the criterion. OTOH, you wouldn't be able to select "*a+", which is a good thing. -- bruce.miller@nist.gov http://math.nist.gov/~BMiller/Received on Thursday, 30 March 2006 23:56:22 UTC

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