Re: proposal by Bruce Smith

bruce@wolfram.com writes:
> As for whether WRI is "running the show" -- we don't think so ourselves;
Again: I was not even trying to imply that, but stressing that
we -- or Dave, as our spokesman -- is clear about this to the
world outside our group.
 
> 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.
The problem is as follows: when ISO International Standard 8879:1986
was published (the IS that describes SGML), there were so-called
informational annexes in it. These are not normative. One of
these annexes contains the ISO public entity sets. These are found
on various archives on Internet, as well as in almost all commercial 
SGML products. However, the working groups responsible for these
matters, in the ISO hierarchy of TCs, WGs that is, have decided
that the informative annexes will be removed from a future revised
version of IS 8879, and that the old ISO public entity sets should
be replaced by the sets in ISO Technical Report (TR) 9573, part 13.
I can send you the lists of entity names and descriptions. If you
want the glyphs (shapes) you have to order a copy of this report
via your standardization body. I suggest that we use these names
and only these names, in all places where we use SGML entity notation.

> >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.
*A* recipe is: take sum, turn it into a normal operator, give it
a superscript * or ' (this ends up in the normal position, and
not on top of the sum), and turn the compound into a large operator.

> This will also be able to handle a restricted class of commutative
> diagrams by using arrow characters in array positions. I don't
As in AMSLaTeX? That will serve as a nice example I think. Ron
will probably agree.  :-)

> >... 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.)
It was Theodore Gray in a message of 4 April 1996.

Nico

------------------------------------------------------------------------
Dr. Nico A.F.M. Poppelier
Elsevier Science, APD, ITD               Email: n.poppelier@elsevier.nl.
Molenwerf 1, 1014 AG Amsterdam           Phone: +31-20-4853482.   
The Netherlands                          Fax:   +31-20-4853706.   
------------------------------------------------------------------------
                  The truth, the whole truth, and nothing but the truth.
                                             And maybe some compromises.