Re: Extensible logical structure:

> Implementing all of AsTeR's recognition on top of the extensibility model
> allowed AsTeR to gain a similar advantage when it came to rendering the
> structure --rendering a teX builtin construct like \over was no different
> and no more complex than rendering the \legendre.

This makes a lot of sense to me. It seems relatively straightforward
to have a file containing the set of operators and templates for mapping
the parse trees into the corresponding trees based on the rendering
schema. I wish I had a good student to work on this, as I am too busy
to make rapid progress on this on my own.

Defining operators is easy enough. This needs to be supplemented by
productions for matching pairs of operators, e.g. left/right brackets,
and integral signs and differential `d's. This too is straightforward.

The next piece is the templates for mapping the input parse tree to
the schema tree. The tricky part is the syntax for variables. In my
first attempt, I used "var(variable_name)" as in:

        map((var(a) over var(b)) becomes over(var(a), var(b))).

This is kind of cumbersome. Prolog treats atoms as variables if they
start with an upper case letter. This option isn't open to us though.
Maybe a modifier character would work, e.g. "$a". If type restrictions
on variables are needed, then it may be worth introducing separate rules
for defining these, as otherwise the number of map rules will multiply
enormously.

I will work further on these ideas.  It may be worth spending time
on coding them up in C with the Arena browser.

Regards,

-- 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