Re: Mathematics for the Web

------- Blind-Carbon-Copy

To: Ka-Ping Yee <kryee@novice.uwaterloo.ca>
Subject: Re: Mathematics for the Web 
In-reply-to: Your message of "Wed, 29 May 1996 21:37:18 EDT."
             <199605300137.VAA26696@novice.uwaterloo.ca> 
Date: Thu, 30 May 1996 12:04:34 -0400
From: "Dave Raggett" <dsr@w3.org>


>> Many people agree that to capture the semantics of math will require an
>> extensible notation.
> 
> I guess i arrived at the same conclusion.  Have you decided to leave
> room for additional "contexts" for structured expression, such as
> chemistry, linguistics, algorithms, and so on?  Extensibility was a
> very big issue in my design.

The short answer is yes. The bigger issue is how to combine different
contexts in a modular fashion, e.g. chemistry and group theory where
each context is defines its own set of notations. Some contexts can
be designed to fit together while others will clash. This looks like
it will need some practical experience to size the problem.

> Yes, this actually sounds very similar to what i am doing.  First,
> an operator parser handles precedence and associativity, and then
> the semantic representation is treated as a macro language that          
> generates the rendering tree.  

I guess the difference is that we would like the operators and templates
to be defined in a file that is used to dynamically initialize the parser,
rather than having the notation compiled into the code.

> I have a hard time seeing how you can get new notations to be "developed
> and extended without any changes being necessary to the browser", though.
> In the case of MINSE the set of rendering primitives is pretty much
> fixed; then, by programming in the macro language, we map the semantic
> compounds to renderings, and can define new compounds this way.

You have pretty much answered the question yourself. The rendering schema
are built into the browser, but the preceding steps are driven by declarative
definitions of the notation which are loaded over the Web.

... on variant notational forms for the same semantics

> I have run into exactly this issue trying to decide whether to give a
> new compound to the dot-bar-dot "divide" symbol as opposed to the
> quotient bar, or to the f "prime" notation for differentiation as
> opposed to the d/dx notation.

This is easy to handle via the declarative definition of the notation,
which can cover the process of mapping the input string to the rendering
schema or clipboard formats for say Maple or Mathematica.

> I have been working on this for a while now without much awareness of
> other work.  Will your work make MINSE obsolete?  Could you provide me
> with any sort of reference to what you are doing and who is working on it?
> I'm rather curious.  This makes me wonder a little about the merit of
> spending so much time on this; i wouldn't mind guidance on how to proceed.

I have set up a small math group at the W3C to work on this. The group
includes representatives from Wolfram, Waterloo Maple, Design Science,
The AMS, Adobe (Raman) and Elsevier. We are currently following two
tracks: the first of which is focussing on defining a notation that
could be released via plug-ins within a few months. The second track
is focussing on ways to declaratively specify semantic notations.

If you are interested in helping with the latter I would be happy
to give you some pointers to where we have got to, and ways in which
you could help with this work. Perhaps you could give me your phone
number for a higher bandwidth conversation.

> My design has taken some pains to limit characters to those allowed
> "safely" within URLs to allow for quick deployment via the "mediator"
> mechanism.  What do you think of this scheme?  (As a separate issue
> from the specification language itself.)

I think that we shouldn't get stuck with the limitations of URLs.
Instead you can use plug-ins for short term work. Have a look at
WebEQ from the Geometry Center at UMN. Rob Miner has written a
Java applet for HTML 3.0 math passing the math via parameters.
It might also be possible to exploit the SCRIPT tag. In the longer
term I hope to negotiate a better approach with the browser vendors.

- -- Dave Raggett <dsr@w3.org> tel: +1 (617) 258 5741 fax: +1 (617) 258 5999
   World Wide Web Consortium, 545 Technology Square, Cambridge, MA 02139
   url = http://www.w3.org/People/Raggett

------- End of Blind-Carbon-Copy