Re: What are your plans for MathML macros?

---David Carlisle <davidc@nag.co.uk> wrote:
>
> 
> > [I wrote] Maybe we ought to have a specification for the external
preprocessing.
> 
> Any such embedding needs to be part of a global picture. It is no use
> MathML on its own defining some interface to this. A typical HTML/XML
> document is likely to have lots of elements containg markup from
> different XML DTD (or possibly even external notations as you
suggest).
> The controlling browser needs to be able to recognise the parts and
call
> out to appropriate code. 

That's why I proposed making a standard specification for turning
arbitrary or almost-arbitrary math-syntax into MathML, so that the
browser is "able to recognise the parts and call out to appropriate
code."


> Having said that, personally I think that it would be a shame
> if something like this became common practice. 
> 
>   <math>
>   <embed syntax="URL_for_my_copy_of_TeX2XML">
>   6 \times 9 = 42
> 
--break--
> 
> Even if the interfaces are finalised that let you do something like
the
> above, the end result would be that your document is only processable
> by a subset of systems, ones that can link in to whatever engine is at
> the end of that URL

It *would* be a shame if the ability to read the embedded syntax were
dependant on the browser having the right plugin. That's why I
proposed what I proposed. What would be at the end of that end of that
URL wouldn't be an engine at all. It would be a set of instructions
looking something like this:

<defop position = "infix">
<define>\times</define>
<as>
<argument position = "1" />
<mo>&Times;</mo>
<argument position = "2" />
</as>
</defop>

<!--more instructions . . . -->

<defop position = "infix">
<define>=</define>
<as>
<argument position = "1" />
<mo>=</mo>
<argument position = "2" />
</as>
</defop>

What this amounts to is a metalanguage for converting near-arbitrary
math syntax to MathML.  The idea is to make it a requirement that any
browser that wants to fancy itself MathML compliant to be able to
understand that metalanguage.

>It is not just static rendering that is at issue,
> we need systems where you can select sub expressions, cut and paste
from
> your web browser into Axiom (or mathematica or maple, or tex, or ...)
> 

Now this *could* be problem with what I propose. If the embedded math
syntax had already been turned into MathML by the browser, it might
not be. I don't think this problem is insurmountable, though. The
solution may be to build into the specification a means of allowing
that to happen.

I think at some point the verbosity of MathML syntax is going to have
to be dealt with head-on. People used to writing HTML or SGML files by
hand (and XML files as they become more popular) will probably resort
to plugins like EzMath or filters similar to HTeX that would require
one to maintain two files for each XML page, if they want to maintain
readable source files. The former make it so that the recipient can
only read the file if he/she has the right plugin, and the latter
introduce the troubles of keeping track of two files, such as keeping
track of which file to edit, and making sure the files have the same
content. I think that human readability of the source file is
important, and others who feel the same will likely resort to
workarounds to accomplish this readability. (Think about the fact that
the EzMath plugin *exists*.) No number of MathML equation editors will
fix that.


==


----I am a fool for Christ. Mostly I am a fool.----

_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com

Received on Friday, 30 October 1998 12:17:15 UTC