SDATA, again

   I would like to repreat my appeal that we revisit the SDATA decision.
I'm sure that no extended rationale was presented for the decision, and
I've been unable to find a record of it at all. As XML stands we have the
private use character codes, which provide no resolution mechanism for
determining which non-unicode character is included in an instance.

   I am asking only that we repalce the numerical values provided by
private-use, with string values. We will still not have a resolution
mechanism, but we will have a foundation on which one can be built.

    I'll also remind people:
   + in DSSSL (at least the near-final draft which I read) characters are
identified primarily by strings, and not chracter codes.

   + since the ISO entities are no longer pre-defined, we will have to
define XML substitutes for them, unless we allow SDATA.

   + since some of the characters in ISO math (and more importantly, TeX
math) are not in Unicode, we may have to assign them private-use code
points, if we don't allow SDATA.

   In concrete, I propose that we allow SDATA entities, and define that
they are _only_ to be used to represent undefined characters by a
descriptive string. We should also reserve SDATA entities of the form
"[XML:" Character* "]" for a future glyph/character resolution mechanism,
if one should be devised.

   -- David

I would also invite some of the new list members that I know have character
set expertise to comment on the alternative of informally assigned
numerical codes versus informally assigned character strings.

I am not a number. I am an undefined character.
David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________