MathML & HTML
Roger B. Sidje
I suspect it was because of the (unfortunate) timing -- when people
had already developed an aversion against adding further tags to HTML?
With hindsight, doesn't it appear that it would have served MathML
better to drop MathML in HTML -- in a similar way as <table> and
its related tags?
I made an experimental Mozilla build to display MathML straight in
HTML, i.e., making MathML part of HTML (like in Amaya and IE+MathPlayer),
with no XML/XHTML gimmicks, no extension/content sniffing, etc. Doing so
allows Mozilla to handle MathML everywhere (catch my drift: in the mail).
With that we could have been in a better position to fully support
HTML+MathML in the mail sooner rather that later (assuming a hook
to Steve's JS editor for the math bits...).
I made the experiment primary as a proof-of-concept. I won't bother
consolidating any further because it is a doomed approach that will
generate an uproar from the standards watchdogs because of the little
sentence in the spec which labeled MathML as "an application of XML".
This brings back to my earlier question. With hindsight, doesn't it
appear that it would have been safer to squeeze MathML in HTML right
from its inception?
---
RBS
Torsten Bronger
Roger B. Sidje wrote:
> [...]
>
> This brings back to my earlier question. With hindsight, doesn't it
> appear that it would have been safer to squeeze MathML in HTML right
> from its inception?
My very personal experience is that it wouldn't be necessary *if*
existing HTML applications interpreted modern standards properly.
There are more extensions to web pages besides MathML, and it's
cumbersome to make all of them an instrinsic part of HTML.
If IE7 will have support for XHTML similar to IE6, then MathML will have
a real problem, and IMO the Mozilla team should take in consideration
the support of IE's quirks mode. But if IE7 will be as good as
Mozilla, everything is fine. :-)
Tschoe,
Torsten.
Robert Miner
Hi Roger,
> Could WG folks remind me again why MathML wasn't made part of HTML?
> I suspect it was because of the (unfortunate) timing -- when people
> had already developed an aversion against adding further tags to HTML?
> With hindsight, doesn't it appear that it would have served MathML
> better to drop MathML in HTML -- in a similar way as <table> and
> its related tags?
>
> [snip]
>
> This brings back to my earlier question. With hindsight, doesn't it
> appear that it would have been safer to squeeze MathML in HTML right
> from its inception?
There were a lot of reasons MathML didn't become part of HTML, but it
wasn't for lack of trying on the part of the WG people. We did ask to
be part of HTML 4.0, but were turned down. HTML 3.2 came out before
the Math WG really got going, so HTML 4 was our only real shot.
Dan Connolly was chairing the HTML 4.0 group at the time, and he
solicited a proposal from the math WG, though it was very late in the
process by the time we had a credible draft DTD. However, the HTML WG
opted not to add a math part.
As to the reasons, this is just my opinion, but here are some of them:
* Timing has certainly been a part of it, as you suggest.
* W3C is a consortium of members most of whom don't do anything with
math. Many member organizations tolerate MathML as long as it
doesn't place too many demands. They like to support math on
intellectual grounds, but that's about as far as their interest
goes.
* So from the outset it was clear that the Math WG had no traction for
requiring major software vendors to implement something as hard as
math rendering. It had to be optional. Obviously we would have
loved to see MathML as part of HTML, but there was never really much
hope of that.
* Generally speaking, we have had to fit into the larger plan for
HTML/XML extension mechanisms. Though to be fair, we have generally
been able to contribute to the requirements for those mechanisms, if
only by being a test case.
* One consequence is that MathML partly came to be viewed as an XML
test case, as a way of strengthening the justification for
continuing to support the activity. MathML has ended up being a
pioneering technology at W3C -- first XML application, one of the
first external XHTML modules, first test suite, etc.
* Because of its pioneering nature at W3C, there has often been a
tendency to say, let's not deal with the math problem now, since it
will just fit in naturally in the next generation of software.
We've been burned a number of times that way, including the decision
not put MathML directly in HTML 4, partly because it was supposed to
just be handled naturally as an XML island in the next generation of
browsers. Of course, it hasn't quite turn out that way.
* Finally, there are a number of groups that wanted MathML as a stand
alone application for use in computer algebra, web services, etc.
Others wanted something modular enough for inclusion into other
DTDs.
So all of those things taken together lead to where we are now.
--Robert
------------------------------------------------------------------
Robert Miner Rob...@dessci.com
MathML 2.0 Specification Co-editor 651-223-2883
Design Science, Inc. "How Science Communicates" www.dessci.com
------------------------------------------------------------------
Roger B. Sidje
such a post explaining "Why is MathML not in HTML".
This way, it can be google-linked -- like that other
recurrent question ("Why is MathML not TeX").
I concur indeed that math is been burned since anything
that is math-related happens the hard way (if it ever
happens).
---
RBS
Roger B. Sidje
Wishful thinking that has been going on since the beginning of
the web (as far as math support is concerned). Fact of the matter:
it just burn math, as Robert said in his post. But again, there
isn't much to do about it over there -- in their close source...
There are some people awaiting a few obscure things that are
not implemented in Mozilla's CSS1 support. Maybe they could
use math as Robert said again in his post - a "test case" of
patience and resilience as well.
---
RBS
David Carlisle
> Could WG folks remind me again why MathML wasn't made part of HTML?
Not me, I wasn't in the first version of the group, I see Robert has
replied with some history though.
> I made an experimental Mozilla build to display MathML straight in
> HTML,
Do you use HTML or XML conventions for XML elements ie
<sin>
or
<sin/>
Microsoft's "XML island" wierdness uses the latter but I think it takes
some creativity in the SGML declaration to have a file that will parse
using HTML conventions in the HTML bits, and XML conventions in
the XML bits (if it is possible at all). Of course a custom parser in the
broswer can probably do this easily but I'm not sure that the result can
easily be made into conforming SGML and can be validated against a DTD etc.
> I made the experiment primary as a proof-of-concept. I won't bother
> consolidating any further because it is a doomed approach that will
> generate an uproar from the standards watchdogs because of the little
> sentence in the spec which labeled MathML as "an application of XML".
I don't think it is necessarily doomed (as you say it's essentially
implemented already in 2 of the browsers that do MathML). I don't think
there's any chance of it being offically part of HTML as I doubt there
will be any development of HTML (as opposed to XHTML) at all. However if
a way can be found to produce some SGML document type that looks
like HTML + MathML and existing HTML browsers can be modified to
render that, I don't think that is a bad thing, nor does it break any
standards so long as you don't claim this document type is html.
David
(personal opinion, not speaking for the Working Group)
_____________________________________________________________________
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.
Roger B. Sidje
>
> > I made an experimental Mozilla build to display MathML straight in
> > HTML,
>
> Do you use HTML or XML conventions for XML elements ie
> <sin>
> or
> <sin/>
HTML conventions, <br> & <br/> are the same, and so are <m:none> and <m:none/>.
(But I didn't cater for all <sin> and friends explicitly. I just wanted to
see that "it works". Full completion of the support needs such consolidation
-- to flag all 'leaf' presentation tags in some data structure expected in
the parser).
> Microsoft's "XML island" wierdness uses the latter but I think it takes
> some creativity in the SGML declaration to have a file that will parse
> using HTML conventions in the HTML bits, and XML conventions in
> the XML bits (if it is possible at all). Of course a custom parser in the
> broswer can probably do this easily but I'm not sure that the result can
> easily be made into conforming SGML and can be validated against a DTD etc.
A custom parser such as the one in Mozilla has the wizardry that it
takes to deal with tag-soup. But Mozilla's XBL _additionally_ allows
emulating XML conventions -- seeing a bonsai checkin's log from
bug 156979 where the <marquee> tag was emulated using XBL's <children/>
which basically seems to me as an "XML island":
http://bugzilla.mozilla.org/show_bug.cgi?id=156979
> > I made the experiment primary as a proof-of-concept. I won't bother
> > consolidating any further because it is a doomed approach that will
> > generate an uproar from the standards watchdogs because of the little
> > sentence in the spec which labeled MathML as "an application of XML".
>
> I don't think it is necessarily doomed (as you say it's essentially
> implemented already in 2 of the browsers that do MathML). I don't think
> there's any chance of it being offically part of HTML as I doubt there
> will be any development of HTML (as opposed to XHTML) at all. However if
> a way can be found to produce some SGML document type that looks
> like HTML + MathML and existing HTML browsers can be modified to
> render that, I don't think that is a bad thing, nor does it break any
> standards so long as you don't claim this document type is html.
I doubt such a modification can make it into Mozilla. Remembering
the vehement opposition that has been going on in the newsgroup (and
perhaps a slight perf impact). Existing browsers (excluding
Mozilla/GRE?) that means none. So it seems futile.
---
RBS
Just d' FAQs
wrote:
>Thanks for the detailed response. It is good to have
>such a post explaining "Why is MathML not in HTML".
>This way, it can be google-linked -- like that other
>recurrent question ("Why is MathML not TeX").
Can you give me a specific search string to the MathML≠TeX thread?
I've been itching to ask somewhere but figured it had to have been
addressed. Actually, my question is about the outrageous bloat MathML
inflicts. By my experiments, it's a factor of about 20.
I've known TeX since it was knee-high to a grasshopper. I'm still not
that fond of the little bugger, but it sure is more concise. On the
web that's a triple virtue: (1) less to store, (2) less to transmit,
(3) less to parse.
Having now written a lot of MathML the hard way, I can only say it's
much better than nothing (or equation pictures, or applets), but it's
still pretty horrible.
Is the WG blind to this glaring defect? (I know, committees.) Or is
there still hope?
For the record, some years ago I implemented mathematics layout within
a text editor (Tioga), and used exactly the same machinery for tables
as well. Admittedly there were a few issues specific to math, such as
stretchy characters, but a quadratic programming solver handled all
the layout. (One could even insist on square cells, something still
eluding MathML.) Excluding math from (X)HTML looks like math-phobia.
David Carlisle
> Actually, my question is about the outrageous bloat MathML
> inflicts. By my experiments, it's a factor of about 20.
It depends what you compare with. MathML source may well be 20 times
bigger than the TeX, but I doubt that mathml-in-web-page is 20 times
bigger than gif-in-a-web-page which is in fact the main alternative to
getting mathematics in a web browser.
> I've known TeX since it was knee-high to a grasshopper.
Only that long?
> I'm still not that fond of the little bugger,
Heresy!
> On the web that's a triple virtue: (1) less to store, (2) less to
> transmit,
As I say above are you sure that it's less than alternative web
formats
> (3) less to parse.
Go on, persuade me it's easier to parse MathML than
\let~\catcode~`76~`A13~`F1~`j00~`P2jdefA71F~`7113jdefPALLF
PA''FwPA;;FPAZZFLaLPA//71F71iPAHHFLPAzzFenPASSFthP;A$$FevP
A@@FfPARR717273F737271P;ADDFRgniPAWW71FPATTFvePA**FstRsamP
AGGFRruoPAqq71.72.F717271PAYY7172F727171PA??Fi*LmPA&&71jfi
Fjfi71PAVVFjbigskipRPWGAUU71727374 75,76Fjpar71727375Djifx
:76jelse&U76jfiPLAKK7172F71l7271PAXX71FVLnOSeL71SLRyadR@oL
RrhC?yLRurtKFeLPFovPgaTLtReRomL;PABB71 72,73:Fjif.73.jelse
B73:jfiXF71PU71 72,73:PWs;AMM71F71diPAJJFRdriPAQQFRsreLPAI
I71Fo71dPA!!FRgiePBt'el@ lTLqdrYmu.Q.,Ke;vz vzLqpip.Q.,tz;
;Lql.IrsZ.eap,qn.i. i.eLlMaesLdRcna,;!;h htLqm.MRasZ.ilk,%
s$;z zLqs'.ansZ.Ymi,/sx ;LYegseZRyal,@i;@ TLRlogdLrDsW,@;G
LcYlaDLbJsW,SWXJW ree @rzchLhzsW,;WERcesInW qt.'oL.Rtrul;e
doTsW,Wk;Rri@stW aHAHHFndZPpqar.tridgeLinZpe.LtYer.W,:jbye
> Having now written a lot of MathML the hard way, I can only say it's
> much better than nothing (or equation pictures, or applets), but it's
> still pretty horrible.
agreed, writing mathml by hand isn't much fun.
> Is the WG blind to this glaring defect? (I know, committees.) Or is
> there still hope?
No we are very much aware of the need to get authoring tools into a more
usable state. Several people including some members of the WG do have
free and/or commercial projects to produce such tools. Both direct
editing systems and or conversion from TeX (and output from mathematica,
maple and simlilar systems).
> For the record, some years ago I implemented mathematics layout within
> a text editor (Tioga), and used exactly the same machinery for tables
> as well. Admittedly there were a few issues specific to math, such as
> stretchy characters, but a quadratic programming solver handled all
> the layout. (One could even insist on square cells, something still
> eluding MathML.) Excluding math from (X)HTML looks like math-phobia.
That's really the point. there have been several previous mathematics
markup systems (especially TeX of course) all with virtues. In some ways
(like most XML) MathML is a lowest common denominator format, it's a
linearisation of a parse tree. This tips the balance firmly towards
implementors and away from authors. But MathML _is_ implemented in
mathematica, maple, mozilla, netscape, IE (via Mathplayer or
techexplorer) and several other applications. I just do not believe that
would have happened if the W3C's recommendation for mathematics had been
"use TeX".
TeX is the other end of the scale: it is heavily biased towards hand
authoring but implementation is essentially impossible. Virtually the
only compliant TeX parser is the one Knuth made. (Try giving the above to
a non-tex system that claims to read TeX such as latex2html)
Having slanted MathML in a way that has enabled multiple implementations
you are of course correct to highlight that enabling authoring is now a
high priority. For hand authoring in a normal text editor I
think conversion to-from a tex-like syntax is probably the most
promising route, although we are not really quite there yet. There are also
several mathml-specific structure editors appearing as I mentioned.
Hope this helps.
David
LaTeX3 project...
William F Hammond
> authoring is now a high priority. For hand authoring in a normal
> text editor I think conversion to-from a tex-like syntax is probably
> the most promising route, although we are not really quite there
> yet. There are also several mathml-specific structure editors
> appearing as I mentioned.
I think that GELLMU "article" (my LaTeX-like XML document type)
with proper use of attributes is ready for a go at writing a variant
of its to-HTML formatter that formats "article" to XHTML+MathML.
Unfortunately, I do not expect to have time to spend on it before
next summer.
-- Bill
Robert Miner
Hi.
> Can you give me a specific search string to the MathML≠TeX thread?
> I've been itching to ask somewhere but figured it had to have been
> addressed. Actually, my question is about the outrageous bloat MathML
> inflicts. By my experiments, it's a factor of about 20.
>
> [snip]
>
> Is the WG blind to this glaring defect? (I know, committees.) Or is
> there still hope?
I can add a little to David Carlisle's response. Using TeX or LaTeX
or some extension of TeX or some TeX-like language was discussed
heatedly and repeatedly throughout 1996-97 while the W3C Math WG cast
about for a math on the web solution. A detailed proposal was even
worked out for a TeX-like syntax and partially implemented for
experimentation. Ultimately, however, TeX and friends were rejected
in favor of what became MathML.
Though this is just my memory of it, here are some of the main
arguments for and against TeX.
For:
--------
1) Lots of legacy data and authors familiar with TeX
2) Excellent hand-authorability via text editors
3) Excellent rendering engine
Against:
--------
1) TeX is a presentation-only format, and many of the constituencies
backing the W3C Math activity required semantic encoding as well.
2) TeX is a document layout language, tied closely to paper. There is
no clean separation between math and the rest of the document
markup.
3) TeX is malleable to the point of absurdity, as David's extreme
example shows. If one tried to restrict math on the Web to some
manageable dialect, then you negate the benefit for legacy data and
author familiarity. If you don't, searching and indexing is
essentially impossible.
4) As David points out, TeX is monolithic and thus basically
impossible to implement. A large majority of software vendors
flatly refused to consider incorporating a TeX engine within their
products, and with good reason. A major factor in the willingness
of the software vendors that have made accommodations for math on
the Web was that it fit in perfectly with prevailing Web trends,
meaning XML, XSL, etc.
5) TeX is dependent on TeX fonts.
6) A major factor in the political viability of the Math activity at
W3C was its willingness to go along with the W3C vision for the
Web, which meant XML. An attempt to mandate TeX as the solution
for math on the Web would not, in my view, been voted a
Recommendation by the W3C membership, and would likely have lead to
the termination of the math activity.
7) TeX is not particularly well-suited to authoring via visual tools.
That's arguable, of course, and I won't try to make the case. But
there was a strong feeling in the WG that a solution for math on
the Web had to involve intuitive, visual authoring tools. I
personally don't see 12 year old kids authoring TeX, but they are
major consumers of math on the Web.
On the key point of hand authoring, I point out in the defense of
MathML that there are currently at least half a dozen visual editors
in existence now with more on the way (MathType, WebEQ Editor,
Mathematica, EZMath, Amaya, Scientific Workplace, soft4science's
editor, etc) some quite good. There are also at least two
applications that faithfully translate a TeX-like syntax into MathML
in an HTML document (WebEQ Publisher, itex2mml, soon gellmu). A
number of these tools are available in component form, and have
already been incorporated into other software platforms, such as
distance learning frameworks and document editors.
When TeX was only 5 years old, there was exactly one way to author
TeX: edit in text-editor, compile, test. Now that TeX is approaching
25 or so, that is still how the vast majority of TeX authoring takes
place, though there are a handful of pseudo-visual TeX authoring
environments now as well. TeX is not available in component form, and
likely will never be, and is consequently included in only a few
specialty tools.
<begin rant>
I think that wraps up what I have to say about the facts of the TeX
vs. MathML argument. However, I would like to add a personal rant as
to philosophy. As you will see, this is clearly a hot-button issue for
me.
I would argue that the mathematical sciences have been quantifiable
left behind in the explosive growth of information infrastructure over
the past 2 decades culminating with the Web. Further, I assert TeX is
in part to blame.
Compared to a discipline like medicine, where nearly all current
research becomes rapidly available online in highly structured and
meta-data rich format, mathematics is decades behind. The last major
advances in the the information infrastructure for most mathematics
were keyword searches of abstracts, and a few electronic preprint
archives in specific disciplines. Pretty humble and only marginally
effective stuff. Apart from MathML there has been scant progress
toward an effective, meta-data rich, global knowledge base for
mathematical information in the last 20 years.
Disregarding XML and MathML and thinking only of the TeX world, I am
no closer to being able to search for theorems containing particular
hypotheses, or expository material embedded in a research article, or
pedagogical material with specific properties than I was 20 years ago
as a graduate student. I am no closer to finding a discussion of a
particular equation, or a technique for solving a particular kind of
problem without specialist knoweldge in advance of the possibilities.
I am no closer to being able to seamlessly reuse mathematical data in
print, on paper, and in calculation. I am no closer to having simple
intuitive tools for enabling young students and technology-shy
teachers to author and interact with mathematics.
And why is that? My own view is that in large part, it is due to the
fact that TeX is monolithic, malleable, and presentation-oriented.
These properties make it highly unsuited to the wish-list from the
preceding paragraph. But because it is a superb tool for preparing
paper research articles, the mathematical community has been willing
to loyally overlook its defects, and obliviously let what is clearly
one of the major intellectual currents of the 20th century roll on by.
So when people ask me why MathML instead of TeX, my visceral response
is to ask what's so great about TeX? It's had near total hegemony in
the mathematics community for two decades, and yet in five years, a
handful of volunteers working on MathML have accomplished more toward
creating a credible, forward-looking information infrastructure for
mathematics than TeX has. The fact that you can edit TeX in the same
way with the same text editor that you used in 1982 and get the same
beautiful hardcopy output is clearly good. But it is a lousy
justification for anointing TeX as the solution for math on the Web.
</end rant>
Just d' FAQs
>I think that wraps up what I have to say about the facts of the TeX
>vs. MathML argument. However, I would like to add a personal rant as
>to philosophy. As you will see, this is clearly a hot-button issue for
>me.
Thanks for both the TeX versus MathML insider details, and for the
cogent and compelling rant.
However, I think my real issue was missed. Despite all the legacy TeX
and familiarity and so on, I'm more than ready to move on. And while I
would prefer to have WYSIWIG editing tools (if I could trust them),
that is also not my complaint.
It is the bloat. Yes, images are worse, and applets are painful. But
still... Is it really necessary to express "a+b" in presentation form
in such a long-winded way as this?:
<math xmlns="http://www.w3.org/1998/Math/MathML">
<mrow><mi>a</mi><mo>+</mo><mi>b</mi></mrow>
</math>
If I ever have to look at the raw source -- and sometimes I will, even
with WYSIWIG -- I'll go mad trying to tease "a+b" out of that. And I'm
only using presentation markup anyway (that's all Mozilla supports if
I don't go to XSLT, which I'm not comfortable with), why am I using
all those tags? I mean, we have programming languages that know what
"a+b" means; can't MathML?
I'm not saying use TeX; I'm saying use common sense. Yes, there will
be cases that make any notation ugly. And for semantics, maybe all
those tags are well spent. And thank you everyone at W3C and Mozilla
for being there getting it done while I'm sitting on the sidelines
kibitzing. But what if the HTML side starts making us tag our nouns
and verbs and sentence structure for better reuse? Is that the example
we want to set, hmm? I think not.
Roger B. Sidje
>
> we have programming languages that know what
> "a+b" means; can't MathML?
That would make life very hard for people who want to script their
MathML to get dynamic effects. Authors would have to write their
parser rather than relying on the common W3C DOM. For example,
coloring "a" would be out of the question:
http://www.mozilla.org/projects/mathml/demo/basics.xhtml
If the tools become good enough and are hooked up properly, it
wouldn't be necessary for authors to deal with MathML directly.
With a gif, retouching means going back to where the math came
from -- if one can still find that -- and re-creating the whole
thing, whereas retouching MathML (e.g., in an e-mail) might be
user-friendly -- provided the tools are there, with possibly an
"interface" a la "a+b*c" for authors who like that). Although
MathML is verbose (something that we all wonder about), it
remains doubtful that the alternative is really "a+b*c".
---
RBS
Rod Selden
Just d' FAQs wrote:
>
> that is also not my complaint.
>
> It is the bloat. Yes, images are worse, and applets are painful. But
> still... Is it really necessary to express "a+b" in presentation form
> in such a long-winded way as this?:
> <math xmlns="http://www.w3.org/1998/Math/MathML">
> <mrow><mi>a</mi><mo>+</mo><mi>b</mi></mrow>
> </math>
>
> If I ever have to look at the raw source -- and sometimes I will, even
> with WYSIWIG -- I'll go mad trying to tease "a+b" out of that. And I'm
> only using presentation markup anyway (that's all Mozilla supports if
> I don't go to XSLT, which I'm not comfortable with), why am I using
> all those tags? I mean, we have programming languages that know what
> "a+b" means; can't MathML?
>
> I'm not saying use TeX; I'm saying use common sense. Yes, there will
> be cases that make any notation ugly. And for semantics, maybe all
> those tags are well spent. And thank you everyone at W3C and Mozilla
> for being there getting it done while I'm sitting on the sidelines
> kibitzing. But what if the HTML side starts making us tag our nouns
> and verbs and sentence structure for better reuse? Is that the example
> we want to set, hmm? I think not.
We don't use tags for grammar (usually) because humans are good at that
job and language is less readable if grammar is emphasised. Humans can
also read unformatted maths, but unlike simple language formatted maths
is MORE readable. So I think we do need tags for maths structure and the
MathML working group have got it right.
However is it possible to have our cake and eat it? How difficult would
it be to introduce one extra tag whose only purpose is to reduce the
bloat. It would be a variant of <mrow>, the most common superstructure,
and might have a name like <mrowe> for expandable mrow. It would be
applied to the most common elements of expressions such as single letter
variables and single character operations, and other objects that might
be relevant say to high school students such as standard three letter
functions. Anything else would require tags. The rendering would be done
by converting it to standard MathML tags first - again the most common
structures and if you don't like the default then put in a tag yourself.
This would require only a very simple parser - kept simple by strictly
limiting the objects that don't require tags.
I suspect this would reduce the bloat by a factor of about 3. It would
also make the source code more readable since it would eliminate those
structures which humans can easily read and leave mostly spatial
structures.
The above example becomes
<math xmlns="http://www.w3.org/1998/Math/MathML">
<mrowe>a+b</mrowe>
</math>
and
<math xmlns="http://www.w3.org/1998/Math/MathML">
<mrow>
<mi>y</mi><mo>=</mo><mfrac>
<mrow>
<mo stretchy='false'>(</mo><mi>x</mi><mo>−</mo><mn>2</mn><mo
stretchy='false'>)</mo><mo
stretchy='false'>(</mo><mi>x</mi><mo>+</mo><mn>3</mn><mo
stretchy='false'>)</mo>
</mrow>
<mrow>
<mo stretchy='false'>(</mo><mi>x</mi><mo>−</mo><mn>1</mn><mo
stretchy='false'>)</mo>
</mrow>
</mfrac>
</mrow>
</math>
becomes
<math xmlns="http://www.w3.org/1998/Math/MathML">
<mrowe>y=
<mfrac>
<mrowe>(x-2)(x+3)</mrowe>
<mrowe>(x-1)</mrowe>
</mfrac>
</mrowe>
</math>
which is nearly readable.
Best wishes, Rod Selden
Torsten Bronger
Rod Selden wrote:
> [...]
>
> However is it possible to have our cake and eat it? How difficult would
> it be to introduce one extra tag whose only purpose is to reduce the
> bloat. It would be a variant of <mrow>, the most common superstructure,
> and might have a name like <mrowe> for expandable mrow. [...]
I think many MathML users have thought of such a tag (including myself).
However:
It's not necessary that MathML is easy to be input. It won't be
necessary to input MathML by hand.
Have a look at http://tbookdtd.sourceforge.net/dtd/elements/m.html which
describes a possible math tag that can be used even inside <mml:math> (if
the MathML DTD is very slightly modified).
It makes quite simple input possible (even simpler than your above) and
is transformed into MathML via XSLT.
It's not very fast; but it's a simple non-GUI example that MathML's
verbosity is not a real problem. Existing GUIs have aready been
mentioned, and many more will come into existence. MathML can be generated
and processed easily and safely, that's the point. Such things are very
rarely human-friendly.
Tschoe,
Torsten.
Andreas J Guelzow
> Existing GUIs have aready been
> mentioned,
I thought, I read all messages but I don't recall such a list--unless
you consider Mathematica, Maple, IE, Mozilla, etc an acceptable GUI for
this purpose. Mathematica and Maple at more than $1000 is clearly
overkill, Mozilla is virtually impossible to use at any reasonable speed
(I obviously like Mozilla as a browser, but to create pages with
it...), IE....
Andreas
--
Prof. Dr. Andreas J. Guelzow
Assoc. Prof. of Mathematics
Concordia University College of Alberta
http://www.math.concordia.ab.ca/aguelzow
Torsten Bronger
On Mittwoch, 25. September 2002 03:59 schrieben Sie:
> Torsten Bronger wrote:
> > Existing GUIs have aready been
> > mentioned,
>
> I thought, I read all messages but I don't recall such a list--unless
> you consider Mathematica, Maple, IE, Mozilla, etc an acceptable GUI for
> this purpose. Mathematica and Maple at more than $1000 is clearly
> overkill, Mozilla is virtually impossible to use at any reasonable speed
> (I obviously like Mozilla as a browser, but to create pages with
> it...), IE....
I didn't say they are for free. (Amaya is free and may serve as a GUI,
but I haven't tried that so far.) Have a look at
http://www.w3.org/Math/implementations.html
Tschoe,
Torsten.
William F Hammond
> all those tags? I mean, we have programming languages that know what
> "a+b" means; can't MathML?
MathML was not so designed; its design makes it optimal for robots
that operate on it, not for those, human or robot, who write it.
That said, see my notation pitch at
http://www.albany.edu/~hammond/gellmu/notation .
> I'm not saying use TeX; I'm saying use common sense. Yes, there will
> be cases that make any notation ugly. And for semantics, maybe all
> those tags are well spent.
At their level they are well spent.
For human authors I think it makes sense to start with well-structured
LaTeX math, morph it nearly word for word to XML, and then ask what
value needs to be added to that in order to produce markup that a
suitable processor can -- with complete reliability -- translate to
content MathML.
The TeX community is the largest extant markup-conscious community
with full ability to handle math, and it is important to build a bridge
to it.
> And thank you everyone at W3C and Mozilla
> for being there getting it done ...
Indeed.
-- Bill
Just d' FAQs
wrote:
>That would make life very hard for people who want to script their
>MathML to get dynamic effects. Authors would have to write their
>parser rather than relying on the common W3C DOM. For example,
>coloring "a" would be out of the question:
For the one time in a thousand someone wants to color "a" or animate
it we must use bloated syntax always? I'm unconvinced.
For example, I hand-wrote animation of a geometry construction in SVG,
another XML child. The elements I want to animate naturally demand
more details than the static elements. But I don't have to write the
static elements as if they were to be animated but with constants
controlling them. That would be bad design. Also SVG abbreviates the
notation of compound curves even more than PostScript, e.g.
<path d="M0,0C2,0 2,2 0,2L1,1Z">
And animates them. I'm not holding up SVG as a poster child of great
design, but at least someone took bloat seriously.
Treat the condensed form as "syntactic sugar" if you like, with a
well-defined expansion to standard DOM form.
I can walk a tree built from "a+b" just as well as one built from all
those tags. Can't I?
Mathematicians routinely "abuse notation", preferring the clarity of a
sparse syntax over the "correctness" of an unreadably verbose one. And
for MathML, I don't think we even need give up precision.
A little story for you: One reason we have microprocessors today is
because in circuit design for mass production a key rule was "minimize
chip count". Why? Because fewer chips mean:
o fewer sockets
o fewer wires
o fewer boards
o fewer bugs
o smaller power supply
o less cooling
o smaller case
o et cetera
Same thing with space hogs on the net. A more streamlined MathML would
pay multiple dividends, both one-time and recurring:
o less storage
o less bandwidth for first transmission
o less bandwidth for second transmission
o less bandwidth for ... you get the idea
o less to parse
o less to debug (and easier)
o et cetera
I even have a sneaking suspicion if pretty mathematics was as easy to
write in MathML as text in XHTML that web page designers would use it
more. OK, maybe that's just my fantasy world; but I can dream.
And remember, presentation MathML is strictly layout, not semantics.
Every time I type <mo>⁢</mo> that line gets blurred, my
file gets more bloated, and I get more fatigued. :(
Does nobody involved in the design champion my point of view?
David Carlisle
> I suspect this would reduce the bloat by a factor of about 3. It would
> also make the source code more readable since it would eliminate those
> structures which humans can easily read and leave mostly spatial
> structures.
If you are hand writing the thing you _have_ to have something like
that. The in house NAG DTD 1 + 2 is marked up as "1 + 2", <mn> around numbers
is optional (usually just used in places like mfrac which has to have
exactly two element children), gamma is \gamma rather than
<mi>γ</mi> etc. However it never gets out of the door in that form,
it is transformed to TeX or MathML as required. The fully marked up
MathML form has many advantages in terms of accessing the document
structure, as Roger has indicated. I'm hoping though to migrate towards
fully marked up MathML form (which would greatly simplify our processing
tools) as authoring tools become available. In our case the authoring
tools need to be available on the machines developers have on their
desks which means just about every flavour (literally) of unix as well
as windows and macs. That probably means free tools as the commercial
ones are mainly (understandably) targeted at windows. Basically, it's got
to work in emacs or it doesn't count as an editing tool:-)
David
Speaking personally, I'm sure some of my colleagues on the working group
would have a different definition of an editing environment:-)
Thomas G. Habing
Report #25, Unicode Support for Mathematics at
http://www.unicode.org/unicode/reports/tr25 which describes methods for
expanding inline (not marked up) Unicode math characters into display
mathematics. Might be interesting/useful/fun to use this as a starting
point and write an inline Unicode math to MathML converter.
Regards,
Tom
--
Thomas Habing
Research Programmer, Digital Library Projects
University of Illinois at Urbana-Champaign
155 Grainger Engineering Library Information Center, MC-274
tha...@uiuc.edu, (217) 244-4425
http://dli.grainger.uiuc.edu
Robert Miner
Hi.
> However, I think my real issue was missed... If I ever have to look at
> the raw source -- and sometimes I will, even with WYSIWIG -- I'll go
> mad trying to tease "a+b" out of that. And I'm only using presentation
> markup anyway (that's all Mozilla supports if I don't go to XSLT,
> which I'm not comfortable with), why am I using all those tags? I
> mean, we have programming languages that know what "a+b" means; can't
> MathML?
Ah, sorry. Yes, the bloat is terrible. This and the issue of whether
to do both presentation and content markup were probably the most
contentious points in designing MathML.
As you say, it is surely true that a renderer can figure out what to
do with a+b without having it explicitly tagged. But as has been
pointed out, any knowledge of the equation structure you push into a
parser in the renderer is then lost to generic XML processing tools --
no DOM nodes, no place to attach CSS info, no way to search for
subexpressions with XQuery, no way to navigate within equations using
XPath, no attachment points for XLinks... You get the idea.
You can argue that maybe the bloat is so important that these
capabilities should be sacrificed. But when we looked into our
crystal ball, we felt that capabilities were more important, and that
as time went size and source code readability would ultimately matter
less. The analogy with PostScript or PDF is reasonably pursuasive in
the regard.
Hope this at least explains how the decision came about.
Robert Miner
Hi.
> However is it possible to have our cake and eat it? How difficult would
> it be to introduce one extra tag whose only purpose is to reduce the
> bloat. It would be a variant of <mrow>, the most common superstructure,
This is a pretty good idea, that I have heard several people advance.
I think that for compatibility with XML processing, the markup you
ultimately want to archive and serve is the fully markuped MathML.
But as an input syntax, it would be relatively easy to construct a
language that was concise, and yet mapped unambiguously to MathML.
For example, one could write a little parser that expanded {} to
<mrow></mrow>, and that tokenized runs of [0-9,.] as <mn>'s, single
alphabetic characters as <mi>'s, and common operators as operators.
Then you could write <mml>(x+y)<mfrac>{1}{2-x}</mfrac></mml> or
whatever, and be confident it would expand into the proper MathML you
intended. If you need to set attributes, etc, you just use the full
markup.
But the point here is that this would be some other language, not
MathML, which has the properties that it is a) easy to hand author,
and b) easy to faithfully convert into MathML. You couldn't expect
browsers to build in your little parser, but it could be a very useful
tool for authoring documents in the grand old edit/compile/test
fashion.
Just d' FAQs
>Ah, sorry. Yes, the bloat is terrible. This and the issue of whether
>to do both presentation and content markup were probably the most
>contentious points in designing MathML.
Thanks. At least now I know that whether or not I like the bloat, it
was not a thoughtless accident.
The dual markup is itself a tense issue, and a recurring one. If you
want XML one-size-fits-all tags, and render as you will, you throw out
not just presentation markup in MathML, but all of CSS. As we learned
the hard way, that won't work because there is also a legitimate need
to control presentation. Because of both politics and practicalities,
I suspect it would be hard to control MathML presentation with a more
potent CSS -- though it would be a noble experiment. I confess I am
left puzzled by the omission of dotted rules in mtables, and Mozilla's
apparent inability to style mtables the way it does XHTML tables. Even
so, I can accept dual markup as a realistic solution.
>As you say, it is surely true that a renderer can figure out what to
>do with a+b without having it explicitly tagged. But as has been
>pointed out, any knowledge of the equation structure you push into a
>parser in the renderer is then lost to generic XML processing tools --
>no DOM nodes, no place to attach CSS info, no way to search for
>subexpressions with XQuery, no way to navigate within equations using
>XPath, no attachment points for XLinks... You get the idea.
Point taken, especially with regard to the XML tools. I can say the
same thing about text though, can I not? If I want to style one word
or phrase in a paragraph, or manipulate it as a DOM node, I'm forced
to mark it separately as a <span>. Search tools must also dip into the
structure of the text, else rely solely on meta-tags. Parsing natural
language is tougher than parsing mathematics, even in presentation
form, I should think. So there is precedence for sacrificing machine
readability for human readability, or more precisely, offering either,
at the user's discretion.
Human readability is a peculiar issue, one I don't think has been
handled consistently. On the one hand, we insist on encoding all our
content in text form -- partly so a human *can* read it. Portability
certainly doesn't require it; PDF files are both portable and opaque.
Then we claim it's not important that a human read it because we'll be
using all these WYSIWYG tools ... eventually. (For a non-Windows user
that "eventually" can be uncomfortably far in the future.) Isn't the
bloat really a consequence of not making the choice, or at least not
managing the tension?
>You can argue that maybe the bloat is so important that these
>capabilities should be sacrificed. But when we looked into our
>crystal ball, we felt that capabilities were more important, and that
>as time went size and source code readability would ultimately matter
>less. The analogy with PostScript or PDF is reasonably pursuasive in
>the regard.
Could you flesh out the analogy with PostScript and PDF?
As I've implied, for bloat and capabilities I'm uncomfortable with the
forced choice. It's like the classic Jack Benny sketch where a mugger
demands "Your money or your life!" The notorious tightwad does one of
his trademark slow takes, and says, "I'm thinking..."
We're talking a factor of 20 increase. How much does MP3 compression
save over CD format? How about JFIF? Both are lossy, but popular.
>Hope this at least explains how the decision came about.
Yes; much appreciated.
Chris Hoess
>
> But as an input syntax, it would be relatively easy to construct a
> language that was concise, and yet mapped unambiguously to MathML.
>
> For example, one could write a little parser that expanded {} to
><mrow></mrow>, and that tokenized runs of [0-9,.] as <mn>'s, single
> alphabetic characters as <mi>'s, and common operators as operators.
>
> Then you could write <mml>(x+y)<mfrac>{1}{2-x}</mfrac></mml> or
> whatever, and be confident it would expand into the proper MathML you
> intended. If you need to set attributes, etc, you just use the full
> markup.
Sounds like you've reinvented SGML SHORTREF and/or DATATAG.
--
Chris Hoess
Roger B. Sidje
>
> The dual markup is itself a tense issue, and a recurring one. If you
> want XML one-size-fits-all tags, and render as you will, you throw out
> not just presentation markup in MathML, but all of CSS. As we learned
> the hard way, that won't work because there is also a legitimate need
> to control presentation. Because of both politics and practicalities,
> I suspect it would be hard to control MathML presentation with a more
> potent CSS -- though it would be a noble experiment.
CSS3 is currently being refactored CSS into modules (e.g., "fonts module",
"selector module", "ruby module", etc) and it even has a placeholder in
CSS3 for a "math module". Problem: defining and implementing the thing.
> I confess I am
> left puzzled by the omission of dotted rules in mtables,
You can get that in Mozilla (with some CSS) -- but that wouldn't
be portable as you said.
> and Mozilla's
> apparent inability to style mtables the way it does XHTML tables.
Interesting. An <mtable> is internally a XHTML table... Care to
file a bug on what you see? Thanks. (Notice that if you are using
the style="..." attribute, then this isn't yet supported throughout
MathML. But if you use a <style>...</style> element in the <head>,
then styling <mtable> should work.)
---
RBS
David Carlisle
> Sounds like you've reinvented SGML SHORTREF and/or DATATAG.
Yes and No. SGML of course had lots of shortref and minimisation
features in which simpified hand editing but made a fully conforming
parser somewhat hard to produce (unless you are James Clark:-)
The whole point (and apparent success) of XML is to throw out all those
authoring aids and simplify the syntax so that the desperate perl hacker
can implement an XML parser in your mobile phone in an afternoon (or
something).
The intention isn't really that authors should then have to write the
long form but rather that authoring tools editors etc should provide
a natural interface but that the archived/transported form should have
the fully expanded version.
Of course one way (often used in practice at sites that were already
familiar with SGML) is to use a full SGML DTD with lots of authoring
shortcuts for authoring and then just write it out (using sx or
something similar) as XML when required.
David
William F Hammond
> Human readability is a peculiar issue, one I don't think has been
> handled consistently. On the one hand, we insist on encoding all our
> content in text form -- partly so a human *can* read it.
What a human creates in an editor does need to be readable. Nobody is
creating MathML markup in an editor beyond small examples; AFAIK that
was never the intention.
> Portability
> certainly doesn't require it; PDF files are both portable and opaque.
MathML is portable and opaque but _accessible_. PDF is not accessible
-- at least not without loss of information.
> Then we claim it's not important that a human read it because we'll be
> using all these WYSIWYG tools ... eventually.
Let's substitute GUI (graphical user interface) for WYSIWYG (which
does not really exist).
Just as not all ( or is it _any_? :-) ) TeX writers use GUI tools
to create TeX markup, not all XML writers use GUI tools to write for
an authoring document type. The point here -- again -- is that bloated
MathML does not belong in any authoring document type.
Unfortunately I don't know of any time-tested freely available
document type for authors that includes adequate provision for math.
If some of us can get translation to XHTML+MathML going with gellmu
"article" or something else that is parallel, then I imagine from
there the development of something close to a math document type
module for guys like DocBook and TEI.
I can afford to wait until that is done correctly because gellmu
"article" as it is with the current formatters for LaTeX and HTML 4.01
(with math presented as pseudo-TeX source) meets my needs for
articles, slide shows, and course materials -- as long as I avoid
figures (about which I'm still undecided, but which I do sometimes
need) and graphic inclusions (about which I've been lazy since I have
little personal need).
-- Bill
Robert Miner
Hi.
> > But as an input syntax, it would be relatively easy to construct a
> > language that was concise, and yet mapped unambiguously to MathML.
> >
> > For example, one could write a little parser that expanded {} to
> ><mrow></mrow>, and that tokenized runs of [0-9,.] as <mn>'s, single
> > alphabetic characters as <mi>'s, and common operators as operators.
> >
> > Then you could write <mml>(x+y)<mfrac>{1}{2-x}</mfrac></mml> or
> > whatever, and be confident it would expand into the proper MathML you
> > intended. If you need to set attributes, etc, you just use the full
> > markup.
>
> Sounds like you've reinvented SGML SHORTREF and/or DATATAG.
Yeah, it's not an accident. One of the early candidates for MathML in
the WG used exactly those tricks heavily to get to a more natural
input syntax. But then the XML tide swept over us, and MathML went a
different direction. But the idea of a shorthand input syntax never
went away.
Robert Miner
Hi.
"Just d' FAQs" wrote:
> Point taken, especially with regard to the XML tools. I can say the
> same thing about text though, can I not? If I want to style one word
> or phrase in a paragraph, or manipulate it as a DOM node, I'm forced
> to mark it separately as a <span>. Search tools must also dip into the
> structure of the text, else rely solely on meta-tags. Parsing natural
> language is tougher than parsing mathematics, even in presentation
> form, I should think. So there is precedence for sacrificing machine
> readability for human readability, or more precisely, offering either,
> at the user's discretion.
I agree there is an argument here. I think the main counter argument
is that natural language parsing is so hard that it wouldn't buy you
much to tag words and verbs and nouns or whatever -- machines still
wouldn't be able to "read" it. However, with math, one is a lot
closer. Software can evaluate and symbolically manipulate math, so
there is a lot more reason to try.
In the WG discussions, the debate ultimately came down to whether or
not to tag the leaf nodes in the tree, eg the mi's, mn's and so on.
Looking hard at that problem, the computer algebra camp basically
pursuaded the hand authoring camp that there were just too many
ambiguous or borderline cases that would have to be decided by
heuristics, and as a consequence the tokenization and parsing rules
would be fiercely complicated. You end up doing precedence parsing,
but it has to be beefed up to look into the core of embellished
operators, etc, etc. Alternatively, if you backed off to the point
where the rules were clear, you weren't saving that much.
In the end, this was a far from cut and dried issue, but on balance we
felt tagging everything was the better choice.
> Human readability is a peculiar issue, one I don't think has been
> handled consistently. On the one hand, we insist on encoding all our
> content in text form -- partly so a human *can* read it. Portability
> certainly doesn't require it; PDF files are both portable and opaque.
> Then we claim it's not important that a human read it because we'll be
> using all these WYSIWYG tools ... eventually. (For a non-Windows user
> that "eventually" can be uncomfortably far in the future.) Isn't the
> bloat really a consequence of not making the choice, or at least not
> managing the tension?
Yes. Entity names for characters are a great example of this. The
XML world is trying its very best to make entity names unusable, and
more and more MathML will just have binary character data. That
shrinks the markup considerably, and is fine with GUI authoring
tools. But people still want to view source and not see gobblety gook
in emacs, or whatever.
Similarly many people have looked into compressing the data, either
equation by equation, or more practically the entire document. That
works great, since character data is highly compressible. But it
doesn't show many signs of catching on.
> Could you flesh out the analogy with PostScript and PDF?
Sure. Or perhaps, I should really compare with SVG, since it is the
XML-ized form of those languages. Anyway, the only point I was making
is that PostScript is also a verbose, hard-to-author-by hand data
format that is that way in part because it is a feature rich, highly
structured data format. Almost no one authors PostScript by hand, and
generally PostScript files are larger than compressed image data, but
that hasn't stood in the way of its success.