Re: HTML-Math proposal

Following are a few comments and reactions I had in reading the
Wolfram proposal.  Bruce seemed to write in such a way as to indicate
presence beyond his own, although this may be only a distinction
between corporate ownership and personal authorship.  In any case, I
do appreciate the effort that has gone into the proposal and think it
will help us a great deal in making our remarks concrete.  Thanks very
much, Bruce.

I also look forward to a means of testing the rendering aspects by
filtering some large quantity of AMS TeX data into the proposed
standard.  "Accurate" rendering (within latitude of human
interpretability) is the highest current priority from an AMS vantage.
If there is further work to be done on AMS data to enable HTML
rendering, the cost of that work will certainly be a factor in whether
AMS actually uses the standard.


Comments on the proposal
------------------------

These remarks are in no particular order.  If I've overlooked
some explicit statements in the proposal which would clarify a
situation, I won't be surprised; just point me in the right
direction!  I'm also not claiming that these items should take
the highest priority in our discussions.  They're for
consideration only.  It's difficult for me to discuss the broad
issue of whether the Wolfram proposal is fundamentally sound
without treating some of the smaller niggly details in the process.
As these remarks are made, I'm thinking both of the lower level
project to filter AMS data into the standard, and the higher level
considerations of whether the proposal is broadly workable and
in accord with the realities of mathematical notation.


1. I wonder to what degree the standard supports nesting of text and
math within math.  String literals support a form of text, but I have
in mind a structure such as

   <math>
     .... <text> ... <math mode=inline> ... </math> ... </text>
     ....
   </math>

One might see this in a statement which involves "cases" or in
situations where some natural language description sweeps over a
perhaps non-existent notational formulation (" ... and all terms
of the form <math> ... </math>").  Often nesting is a more
natural mode of markup than alternation between text and math in
these situations.

I understand the math interpreter will have to handle SGML-style
notations in reading entities and math markup, but do we have in
mind that the math interpreter also has to interpret standard
HTML code in a text element within math?  (And further interpret
math within that text element?)


2. I think there are many font calls in math which are most naturally
expressed as (say) prefix operators, and not in the normal HTML method.
It may be that distinguished methods would lead to confusion, although
I'll mention that AMSTeX and AMSLaTeX distinguish between "textual"
font changes and math font changes, and users seem to have accommodated
themselves to this.  Font calls as operators also accord more with
their function as "embellishments", as an accent might be regarded
(so that "&tilde; f" and "&bold; f" remain parallel).


3. I'm uncertain as to whether "embellishing" an operator on the left
via a font call or an accent is read as such.  The language

     When an operator is directly followed by another
     (postfix or infix) operator with the attribute
     embellisher=true, the first operator is "embellished"
     by the second one (and by its right operand, if
     any). The parser generates an internal expression
     headed by moperator (before applying transformation
     rules), and treats it as if it was itself an operator
     with the attributes of its "base" (the embellished
     operator), i.e. uses them for parsing the surrounding
     source text.

makes me think that "&tilde; +" may be regarded as something else.
How is embellishment-from-the-left handled?


4. I wonder if it makes more sense to use the ISO12083 approach
as a basis for the fundamental layout schemata rather than TeX.
I'm only thinking this might help upward compatibility.  I
haven't looked at details, but do think that this is exactly what
ISO12083 was up to.



5. I hope that in the end the precedence values have a more
abstract front-end for users to interact with.  Hard-coding
something like "400" for a precedence value may well lead to
trouble (i.e. rigidity) down the road.  How many different values
are there at the moment?  I would think that extensibility would
better be achieved by ordering a new precedence abstractly within
existing precedences rather than assigning an absolute value.
This would also get over the (perhaps not-terribly-worrisome)
discreteness characteristic of the natural number ording.  It
seems better to use a dense ordering as a basis than a discrete
ordering.



6. The proposal treats relational signs such as "=" and "<" as
operators (presumably with truth values as range).  I am assuming
that the standard visual rendering which places more whitespace
around these symbols than, say, binary operators such as "+" and
"*" would be achieved on the basis of precedence values.  Is this
true?  The lower the precedence the wider the space?  Done on a
continuity basis (this might make things harder to read)?  Is
this for infix operators only?



7. I have some vague misgivings about a lack of symmetry in our
notational forms.  While symmetry breaks down under rendering, I
would like to achieve more symmetry in the underlying methods
treating the notation.  The remark above regarding font calls as
operators is in this vein.  At the moment I can't describe the
style I would like in any productive way.  I'll say more when
I feel I can capture the point better.



-Ron