Re: MathML capable browser

Hi Bill,

> Presumably there could be an arrangement, where one would only
> need to serve voyager-xml with xsl code only for the non-html tags
> in order to have something useful with xsl code for the html tags
> being optional, tag by tag.
> 
> That said, a browser then could have "internal" knowledge of default
> xsl code for MathML working under the mainstream xml/xsl engine.
> 
> Is this the game?

I think that is more or less correct.  I have been really swamped
lately and am a little bit out of the loop.  But this is more or less
what I know.

On MathML in Netscape:
----------------------

   Rick Gessner, who is in charge of Netscape's NG (next generation)
layout engine spoke to the MathML working group in Longbeach in
October, to essentially give the group a crash course on what to do to
integrate MathML into NG as part of the whole Open Source project.
There were two main chunks -- developing a subclass of a general
parsing/DTD object that would teach the parser about MathML, and
developing a subclass of a line layout engine that could render the
resulting DOM objects.  Obviously, it is more complicated, but that
was the gist.  He also very much encouraged the Math group and their
respective organizations to at least give it a whirl, so that the
right stubs and callback could be introduced into the code while its
still in flux.  Once that has happened, presumably it will be possible
for a much greater diversity of groups to easily work on MathML
"plug-ins" that actually interact properly with the surrounding
browser.

   I guess the relevant points here are that 1) this would require
"native" C++ work to accomplish, and 2) at the same time, a MathML
implementation would get to leverage a lot of serious, general purpose
XML/DOM machinery, and would only have to do the math-specific bits.

   I am not sure what confidentiality agreements I am bound by, so I
better stop there, except to say that something along these lines is
being looked at by somebody or another, blah, blah, blah... (I apologize
for the secrecy, but it isn't my call.)

On MathML in Internet Explorer:
-------------------------------

   Here I believe the situation is a bit more like the math group
originally anticipated.  The XML parser sucks in MathML fragments and
adds them to the DOM (I'm not sure if it parsers it without a DTD or
if something needs to be done to instruct the parser about MathML).
At that point, IE5 has something called "behaviours" that can be
attached to elements that teach the browser to do the rendering.
Obviously, I am not as well informed here, but my impression is that
some things could be done at a high-level, with essentially stylesheet
type commands, but that its always possible to implement behaviours
with compiled code modules for performance, or flexibility, etc.

   The same weak assertion as above also applies here -- people are
actively looking into this, and Microsoft is being helpful.  Details
to follow...  (Also, on a different front, Murray Sargeant from
Microsoft joined the Math WG.  He is their Unicode committee rep, and
his help shepherding the STIX proposal through the committee can't be
under estimated.)

On Voyager
----------

I even more in the dark here, but I think you might be selling it a
little short, to describe it as Dave Raggett's baby.  When I talked to
Dave in Longbeach, he had just come from the first meeting of the new
HTML working group, and they were all fired up about modularizing HTML
in the way you describe, with transition strategies, etc.  Knowing
Dave, he is a very effective advocate at W3C, and he is in up to his
eyeballs in Voyager, so he certainly deserves the credit.  But the
point I want to make is that I think the trend Voyager represents has
pretty broad support from a lot of W3C organizations.

--Robert

Received on Thursday, 17 December 1998 11:22:00 UTC