# Re: Formal query about WG role and MathML-FAQ

Date: Tue, 14 Mar 2006 11:09:52 -0800 (PST)
Message-ID: <3272.217.124.88.157.1142363392.squirrel@webmail.canonicalscience.com>
To: <www-math@w3.org>


>> Bruce Miller said:
>
>To get to what seems to be your point:
>
[snip]
>
>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...)?
>

It appears as you are attempting to trivialize the research. Do you really
believe that important questions are if one prefer <mfrac> to <frac> or
<fraction> or even <f>?

>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?
> $> TEXT: a > <frac/> > TEXT: { 2 + b > <frac/> > c } >$

Yes the DOM like strange. That is reason I said one could probably prefer
grouping via explicit tag instead of using { and }.

But the tree structure for example for <CanonMath>a<frac/><g>2 + b <frac/>
c</g></CanonMath> is rather natural

<CanonMath>
a
<frac/>
<g>
2 + b
<frac/>
c
</g>
</CanonMath>

from a *document* point of view. In fact, I explained how that kind of
markup (namely mixed markup) is formally similar to usual HTML documents
(look examples I introduced, the figures of trees and the comparison with
a typical <i></i> HTML example). MathML is based in pure markup or “data
oriented”.

>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?

Then empty elements are permitted in Content Math and XHTML but are not in
others ways? I am not sure, but apparently you find a great disturbance

<CanonMath>
<textnode>a</textnode>
<fraction/>
<textnode>b</textnode>
</CanonMath>

but not trouble with

$<apply> <divide/> <ci>a</ci> <ci>b</ci> </apply>$

Yes, You are right, the abandon of XML and the use of textual islands as
in LateX code embebbed into HTML or XML documents is an option. However,
IteX, TeX/Latex, and ASCIIMath formats are not suitable input sintaxes for
us.

In my reply to David Carlishe I addes some examples of XSLT. What is more,
I know people who has translated such as $$1 \over {x+1}^2$$ to
presentation MathML using XSLT. It would be not difficult to adapt the
XSLT to the case

<CanonMath>1<fraction/>{x+1}^2<CanonMath>

or maybe

<CanonMath>1<fraction/><g>x+1</g><power/>2<CanonMath>

>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?

I think that one easily see next benefits with proposal:

- Easier input syntax

- single markup instead of double (presentation AND content)

- possibility to extension to science that has not MathML was not designed
for that (therein the developing of many scientific XML languages such as
CML)

- I already explained trouble I experienced with MathML tools (incorrect
output, lack of semantics, bugs, needs of fine-tuning by hand, etc.)

- Examples such as that of Hermes I detailed would be not permitted in new
sintax is being designed. This favours a clean web, which is one of
pillars of the vision of the w3c. Or you are supporting the use of TeX,
which is next transformed into MathML + XHTML via Hermes for outputting
empty paragraphs for layout and authors or dates encoded as headings of
level 3 both deprecated and discouraged by last W3C specifications and
recomendations?

- Etc.

<CanonMath><_>a + b<fract/>c + d</_></<CanonMath>

(or similar) one still prefers over

<math xmlns="http://www.w3.org/1998/Math/MathML"
display=“block”><mfract><mrow><mi>a</mi><mo>+</mo><mi>b</mi></mrow><mrow><mi>c</mi><mo>+</mo><mi>d</mi></mi></mrow></mfract>[/itex]

or not?

Note that there is not a great increasing on the complexity of input
syntax of CanonMath when compared to pure TeX

<_>a+b<fract/>c+d</_>

\fract{a+b}{c+d}

In other cases I listed, syntax is far more easy that with TeX/LaTeX.

>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)
>

As already explained, ASCIIMath is a nice textual syntax with a
well-defined niche. The modification of ASCIIMath for more general
purposes would finalize with some completely different therefore I see not
the point. If, however, if you are asking for the possibility for a
textual version of CanonMath can be enclosed in a XML document

Some as

<CanonMath>{a + b fract c + d}</<CanonMath>

it could be. I also am valuating that possibility. Then would I also
abandon the XML scientific module by a textual version? And what about the
CanonText module? Also abandoned and just transformed into XHTML on the
fly? Hum, interesting suggestion...

In fact, many people dislike XHTML angles and is working with alternative
syntaxes. The Wiki is a popular example.

>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.
>

Anyone is free to read, comment, correct my errors, provide suggestions to
main points I are highlighting. In fact people, is doing both in private
or in public.

>
>--
>bruce.miller@nist.gov
>http://math.nist.gov/~BMiller/
>
>

Juan R.

Center for CANONICAL |SCIENCE)

Received on Tuesday, 14 March 2006 19:10:21 UTC

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