Re: proposal by Bruce Smith

Sorry for the delay in replying to these questions.

>Here are my comments and questions on the proposal recently distributed
>by Wolfram Research.
>
>1. What are the sources of inspiration for this proposal? Or,
>to be more direct: is this similar or identical to Mathematica?

The proposal has a lot in common with Mathematica 3.0's typesetting
system, and was directly inspired by it, but is different in many
details.

As for the extent to which Mathematica can be considered a "proof of
feasibility", this is true about the linear syntax (except for tensors
and prescripts) and about the parser itself (which I should emphasize
is certainly not yet fully specified by the letter I sent, which only
discussed some of its characteristics). This is also true about the
character set (again not yet fully specified) and about the general
philosophy of using different extended characters with similar
appearances for different meanings. And it's also true about the set of
layout schemas, again with the exception of tensors and prescripts.

Soon I will complete the proposal outline I already sent, and soon
after that (I hope) send a detailed specification of the aspects which
still need one, especially the parsing algorithm and the
character/operator dictionary.

As for whether WRI is "running the show" -- we don't think so ourselves;
what we're intending to do is to complete a concrete proposal which is
able to serve as a basis for further discussion and amendment. We, of
course, will decide how to amend the version that we are proposing (and
in doing so we'll certainly try to take into account the group's
concerns), but the group as a whole (as led by Dave) will decide whether
to accept our proposal at all, and if so, how to amend it.


>2. Concerning special characters: I think it is more accurate to
>write "most of which are not part of Unicode" instead of
>"not all of which are part of Unicode". I have been in touch
>with Anders Berglund, the editor of ISO Technical Report 9573
>(latest version is from 1991), which contains lots of these
>special characters. We are trying to harmonize the Elsevier
>Science set with the set in ISO TR 9573. Anders has also been in
>touch with the Unicode people, but they have never answered to
>his proposal to add all special characters in ISO TR 9573 to Unicode.

Our proposal, when complete, will come with a character set and one or
more entity names for each character, but we'll be glad to add more
characters and names from standards which are thought to be important
to support. We already include the characters and (alternate) entity
names from at least one ISO standard which is used with SGML, but I
don't personally know which one (I'm asking and will tell you when I
find out). If this was not ISO TR 9573 we'll certainly look into adding
that.


>3. Stretchiness of brackets is not 100% static. I mean: I some cases
>the user/author should be allowed to differentiate between
>( ... ) and \left( ... \right) as in TeX. In the first case the
>brackets are not stretchy and in the second case they are.

Quite right; I'll deal with this when I next amend the proposal.
Brackets will by default be stretchy but will be able to be modified
(with each use) to not be (or to have revised stretchiness parameters).


>4. A similar remark for rendering of limits on a sum or integral:
>what is described in the proposal is the default, but the author
>should be able to override the default.


>5. Another remark about large operators: I did not find an explanation
>of how to obtain sum' from k=0 to infinity or sum* frm k=0
>to infinity, i.e. with a summation that has an ornament in the
>normal superscript position. (I know how to do it in TeX, but
>I'll spare you that :-).

Good points; I had not adequately dealt with these in my proposal,
and will do so in the next amendment.


>6. I think a necessary ingredient of (5) is the reverse of "mlargeop":
>make a regular operator out of a large operator.

I'm not sure why this is necessary for (5), but it is probably desirable
in any case, so I'll add it.


>7. I found the explanation of % ^ _ terse (almost cryptic).

Granted; I wrote that section in a hurry and it needs to be much better
explained. Again, I'll try to fix this in the next version.


>Same for the concept "aligned pair", and the application to
>tensor notation (with which I should be familiar, since I am
>a theoretical physicist. :-).

I meant a pair consisting of one subscript and one superscript
on the same "base", which ought to be vertically aligned when rendered.


>8. The case where an entire pair of vertically aligned indices
>is empty is indeed rare, but we have found examples of it.
>So what is the solution to this (or workaround)?

The use of invisible identifiers (or string literals), of the desired
width, as the subscript and superscript.


>9. What is the equivalent of a^{b^{c}} in TeX (with c in smaller
>font than b, which is in smaller font that a)? Surely
>not the mbox construction?

Just a^b^c, since ^ is right-associative.


>10. I am looking forward to treatment of the additional topics
>arrays, commutative diagrams, ...

I understand that Dave is going to propose a layout schema and notation
for dealing with arrays or tables, based on his earlier draft proposal.

This will also be able to handle a restricted class of commutative
diagrams by using arrow characters in array positions. I don't
anticipate adding more general commutative diagrams to the first
complete version of the Wolfram proposal (although I think they're
important, as are structural chemical diagrams), since they are quite
hard to handle in general. I do think we (the HTML-Math ERB) should
tackle them at some point, but that we should not hold up the rest of
the project for that. Perhaps the best way to approach them will be to
provide a means for allowing additional nonstandard layout schemas to
be supported by specific renderers, as well as allowing authors to use
macros which can expand into uses of these nonstandard layout schemas,
so that someone else can experiment with the more general layout schemas
needed for these constructs.

>... multi-line equations with horizontal
>alignment and equation numbering (I was promised
>an explanation of Mathematica's mechanism for this a couple of
>months ago, but never got it :-( ).

I'll include these in the next amendment. (If you remind me who promised the
explanation I'll remind them to provide it.)

- Bruce