| May I assume that this char->glyph mapping is outside the scope of
Yes, this is true. Maybe the example with TeX as the back-end was a bad
example, since I didn't want to use it for char->glyph mapping. Such
is, strictly speaking, only possible in the application, since the
parser doesn't know what the data characters are supposed to mean, in
the eyes of the application. All I'm doing with my model is allow them
to agree on an encoding that both will be happy with. It is, after all,
up to the application to support the parser or entity manager with the
"display version" for the public entity set references.
Still, an SGML document _must_ allow a user-specified char->glyph
mapping, og perhaps user-specified glyphs. The only way this can be
done is with entity references to a glyph ID of some sort.
| [I've seen early drafts of DSSSL in which this process is made
| explicit; however, I saw no evidence that those drafts take into
| account the generality of the char <-> glyph relationship. Perhaps
| that has been rectified by now?]
I'm not following the DSSSL work as closely as I feel I should, so I
can't answer this, unfortunately. It's an important question.
| I completely agree with this model. Applications will continue to
| use old character sets forever. 10646 is a good choice as a canonical
| representation for a parser, with conversion to/from extant charsets
| at the boundary. I think many systems will use this model.
Thanks. I'm writing on a specification for this model, and will send
you (and anyone else who might be interested) a copy upon completion.
Erik Naggum | ISO 8879 SGML | +47 295 0313
| ISO 10744 HyTime |
<[log in to unmask]> | ISO 10646 UCS | Memento, terrigena.
<[log in to unmask]> | ISO 9899 C | Memento, vita brevis.