- From: James Ramsey <jjramsey_6x9eq42@yahoo.com>
- Date: Fri, 30 Oct 1998 09:16:54 -0800 (PST)
- To: David Carlisle <davidc@nag.co.uk>
- Cc: www-math@w3.org
---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