After Parrot, what next?

[David C. Ullrich]

On 14 Apr 2001 16:10:35 GMT, neelk at alum.mit.edu (Neelakantan
Krishnaswami) wrote:

>On Wed, 11 Apr 2001 16:00:45 GMT, David C. Ullrich <ullrich at math.okstate.edu>
>wrote:
>>On 10 Apr 2001 11:54:35 GMT, neelk at alum.mit.edu (Neelakantan
>>Krishnaswami) wrote:
>>>
>>>You're too late.
>>>
>>>  http://www.w3.org/TR/xexpr
>>>
>>> Yes, I thought it was a joke at first too, but no joy. How can
>>> anyone possibly consider this a good idea? The mind boggles. :(
>>
>> The fact that TeX already exists does not mean there's no need
>> for MathML, nor is MathML a replacement for TeX; they have 
>> different uses in different domains.
>
>Bah. If you made the argument that MathML is needed because when
>sending equations over the network it's a good ideas if the equation
>language is not Turing-complete, I'd agree.

I see two points to MathML: One is that it's an XML application, so
_in_ a context where we're already parsing XML anyway it works
very nicely. In a context where we're parsing XML documents
into trees (ok, "parse" is a little strong there) the equations can
be a part of that tree; we have one document that actually
_includes_ the structure of those equations. When we display
the thing we can use a style that applies to the entire document
instead of the document treating the equation as a black box
to be displayed by something else.

Seriously. To give just one explicit example, I tend to run at
a high resolution - there are a lot of web sites out there that
are more or less impossible for me to read at 1600x1200.
For the text part I simply hit a button and the font size increases
and then I can read the text (except when someone has
insisted on setting the font size to some absolute value in
some style sheet, because they don't want people to be
able to read their site at anything higher than 800x600.)
Happens all the time that I hit that button, the text becomes
legible but the equations are still tiny. A browser _could_
simply stretch the output of the black box to give ugly
pixellated large equations, like when you stretch a bitmap.
Or a browser could know _somehow_ how to tell the
black box to ouput a larger equation - this requires the
browser to know something about how that black box
works. Or _if_ the equations are actually part of the
document that the browser itself is displaying then
the browser simply stretches the equation along with
everything else in the display.

Displaying equations on web pages has been a big
problem for a long time - those guys actually had a
reason for inventing MathML. (Yes, the browser has
to learn somehow how to display MathML properly
for this to work. But teaching the browser to display
MathML is much easier than teaching it to display
TeX: It already knows how to parse the MathML,
and when it parses it it gets a tree that's just like the
tree representing the rest of the document; the 
display could be handled by a style sheet.)

That's what I see as one point to MathML instead
of say TeX: the fact that it's actually part of XML
offers significant advantages, _in_ _some_ _contexts_,
or so it seems to many people. Similarly _when_
we are embedding a script in an XML document
it seems like there must be _some_ point to making
the script itself a dialect of XML.

(The other point I see to MathML over TeX is that 
as long as you stick to the right half of MathML it
actually describes the logical structure of the
equation. TeX does no such thing; TeX describes
the structure of the pattern of black dots on the
page, and if you want to get from there to the
actual mathematical content you have to interpret
the marks on the page correctly. TeX is if anything
much more powerful and flexible and easy to use
as a language for specifying patterns of dots on
the page - in part this is _because_ that's all it
does, ignoring the logical structure (ie allowing
me to write 

x = y +*/)(z -

if I feel like it even though that does not mean
anything.))

>But for an actual programming language there's no win at all in a
>language using XML as its concrete syntax. That's the easiest part;
>there is no leverage to using XML there.

_If_ we're talking about teensy scripts in documents which are
like _documents_, not source code, there's _no_ advantage
to having the scripts in a language that gets parsed by exactly
the same parser as the rest of the document?

> You can't even use it to make
>automatic program generation easier because there's no standard
>mechanism to avoid variable capture.
>
>If you want a custom XML transformation language, DSSSL is better,
>already exists, and is designed for this domain. It has an actual
>semantics; it is more expressive; and it is easier for humans to read
>and write.

I don't know of any studies, but it seems clear that TeX is easier
for humans to read and write than MathML. Many people
see MathML as a very good thing - this is not because anyone
has ever claimed it was easier for humans to read and write.
I can't imagine people writing large mathematical documents
by hand in MathML, the way people write TeX.

But that has no relevance whatever to the reasons I feel
there's some point to MathML even though TeX already
exists - I don't think that MathML is _intended_ to be
read and written by hand by humans. I think that anyone
who declares that there is no point to MathML because
TeX is easier for humans to read and write is missing
at least part of the point. 

I don't actually _know_ that there is any point to
the http://www.w3.org/TR/xexpr thing, but I don't see
how people can be so certain it's pointless. Nobody
said it was supposed to _replace_ all the programming
languages in the world.

>Neel