Re: Extensible logical structure:

As I understand it, the important features of AsTeR's extensibility
mechanism (as you describe them in your letter) are:

- you can declare new operators to have any of the same parsing
attributes that preexisting operators have;

- all operators, preexisting and new, are implemented by separate
stages of (1) parsing according to their attributes, followed by
(2) translation into some (non-extensible) set of layout primitives,
using some kind of table or other externally specified rules, rather
than using rules which are built into the code.

I fully agree with this approach and will support one like it (when
it's properly done) for HTML-Math.

--

I don't know if you ever had a chance to read my now-obsolete
"position papers", but they described a similar proposal for
HTML-Math, though without any details of the syntax for declaring
new operators. (I did give examples of a syntax for specifying
transformation rules with which to define the rendering of both
old and new operators.)

--

My new proposal (to be mailed to the list any day now) will not
include an extension language, but it will be structured in such
a way that adding a very flexible one would be straightforward --
namely, there will be a parsing stage followed by a translation
into an internal form for rendering, either of which could in
principle be entirely table-driven, and therefore could be made
extensible. The fact that these stages are strictly separated is
what guarantees that this extensibility would be straightforward.

I want to get this concrete syntax (and set of layout primitives)
on the table for discussion (and possible approval), before discussing
concrete syntaxes and semantics for extension rules. If there is
anything about my proposal which would make it unnecessarily
difficult to add extensibility, I'll want to change that immediately
-- but I think that question can be discussed separately from the
details of how extensions are actually specified and precisely how
extensions from multiple sources should interact, which I think is
a harder problem in general.

--

I think Dave's letter about how this can be done is on the right
track, as was our prior discussion in the group on these same
issues, but I think it will take us some time to get these details
right and it will be valuable to have a specific proposal for the
layout schema and the concrete syntax prior to extension already
agreed upon while we work on them. (In fact, I think this will
speed up our work on extension notations.)

Since both Dave's approach (as I understand it from his latest
letter) and the approach described in my old position papers are
fully general about the input and output expressions that can be
transformed, I think there is no danger that they would fail to be
able to be used to define whatever concrete syntax we agree on.

--

A final note, on your analogy from the conference call of the
translation from HTML-Math source to a renderable "display list"
as a function from a domain to a range, and your worry that if we
specify the range first, we might have trouble mapping into it --
I think we have to be careful to specify the range in a clean,
uniform way, and if we do so, it will constrain only the layout
schemas that can be used, and not how they can be used.

- Bruce