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 \__________________________