From: Bruce Miller <bruce.miller@nist.gov>

Date: Tue, 14 Mar 2006 11:32:10 -0500

Message-ID: <4416F00A.2070901@nist.gov>

To: www-math@w3.org

Date: Tue, 14 Mar 2006 11:32:10 -0500

Message-ID: <4416F00A.2070901@nist.gov>

To: www-math@w3.org

juanrgonzaleza@canonicalscience.com wrote: > > Bruce Miller said: > >>juanrgonzaleza@canonicalscience.com wrote: >> >>>Dear sirs, >> >>You seem to be demanding an official response of the Math WG. >>I cannot give that, but can reply individually. > > Just seem? Well, I was trying to be polite; it sometimes helps. [snip] To get to what seems to be your point: >>Devising an alternative input syntax that can be converted >>to MathML, or OpenMath or such, seems a perfectly legitimate goal. >>While your proposed syntax may be somewhat more concise >>than mathml, IMHO, it seems to give up a lot to get there. The infix >>notation would seem to be difficult to manipulate with DOM and XSLT, and >>would be even more incompatible with CSS (for full rendering w/o native >>support) than mathml is. In other words, it doesn't particularly solve >>any problems that I personally need solved; but that, of course, does >>not mean that your ideas are bad or wrong or whatever. > > > Yes, the infix notation is more difficult to manipulate via DOM or XSLT > and there are difficulties to use with CSS. I already said that in the > website time ago! I carefully said about those problems and how I was > trying to solve them (XPath, XSL-FO, etc.) > > In fact, the template needed for transform from infix notation to MathML > markup would be as "complex" as 10-12 trivial lines of XSLT. First one > transform from mixed to pure markup in block via a template, next one > selects the text nodes already tokenised via XPath positions before/after > the operator tag (e.g. <fraction/>). > > Again, I fail to completely understand you. Apparently, you are claiming > that infix notation would be an impediment for the success and, > apparently, you take this point against CanonMath development I have read > you correctly here. Take the example of ASCIIMath, it is listed at w3c > website as one of input sintaxes for MathML; ASCIIMath works with both > infix notation and DOM manipulations. It is so (in)compatible with CSS as > MathML already is. I'm not sure what more I can say here; I'm not even sure what the question is. Is it whether I prefer <mfrac> to <frac> or <fraction> or even <f> ? Is it whether I prefer prefix to infix (or more likely "natural" notations with mixtures of infix, prefix, postfix, all with various precedence, sometimes whose precedence depends on context...)? First, I would reinforce David's comments about mixed markup. To take one of the examples from your posting: a<frac/>{2 + b <frac/> c} The DOM for that is rather strange, isn't it? <math> TEXT: a <frac/> TEXT: { 2 + b <frac/> c } </math> Rather than pretending to use XML, wouldn't it be better to use Unicode or some other character entities, instead of the empty elements? You seem to be claiming that it is trivial to convert these forms to MathML with XSLT; Have you actually tried this? If you move this form more towards XML, to clarify the grouping and such, you've ended up with something surprisingly close to MathML; Where's the benefit? OTOH, if you move this form towards a pure text, you've ended up with something surprisingly close to Asciimath. Are the problems with AsciiMath really unsolveable? (whatever they are; I'm not that familiar) More generally: I don't believe it is fair to demand a response from any particular person or group. I think the best you can do is to post a clear and concise request for comments to some public forums (fora?) [www-math is such a forum; it has not only Math WG members, but many other parties interested in math, math on the web, etc, who are free to comment, or not, as they wish.] with the hope of finding people interested in your approach that are willing to contribute. Alternatively, try to ask specific questions. -- bruce.miller@nist.gov http://math.nist.gov/~BMiller/Received on Tuesday, 14 March 2006 16:30:05 UTC

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