W3C home > Mailing lists > Public > w3c-math-erb@w3.org > June 1996

ISO TR 9573, part 13

From: Bruce Smith <bruce@wolfram.com>
Date: Tue, 11 Jun 1996 13:44:35 -0700
Message-Id: <v0213051cade384b09d35@[199.182.131.168]>
To: n.poppelier@elsevier.nl
Cc: w3c-math-erb@w3.org
[was: Re: proposal by Bruce Smith]

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

That would be helpful -- especially if you have a list which
correlates them with the old names from 8879, which are probably
what we used in Mathematica as "SGML names".

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

Is there a problem with using more than one name per character?
It seems to me that it would be useful, and have no significant
drawbacks, to allow authors to use (independently for each character
in the document) either the old 8879 name, or the new 9573 name, or
a long and easy to remember name (as used in Mathematica) (assuming
there are no naming conflicts). Otherwise, by disallowing 8879 names
we introduce needless incompatibility with existing documents and
code, or by disallowing long easy-to-remember names we needlessly
make it harder for authors to learn character names.
Received on Tuesday, 11 June 1996 16:44:48 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 15 April 2023 17:19:57 UTC