On Wed, 11 Sep 1996 11:24:42 CDT Peter Flynn said:
>... is interpretation of &foo; in a CDATA attribute literal _mandated_
>by 8879 or is it optional for the application?
It is mandated. Clause 7.9.3 says it explicitly, though in what some
readers have found a rather convoluted way.
The formal grammar of SGML foresees two forms of "attribute value
specification", namely "attribute value" and "attribute value literal".
(This is the point of production number 33, in clause 7.9.3.) The latter
have quotation marks, the former do not. So if you say
<FOREIGN LANG=iw REG="ℵ">A</FOREIGN>
then the LANG attribute has its value specified by an 'attribute value',
and REG is given an 'attribute value literal'. Clause 7.9.3 says
"An attribute value literal is interpreted as an attribute value by
replacing references within it, ignoring Ee [entity end signal] and
RS [record-start character], and replacing an RE [record-end character]
or SEPCHAR [tab] with a SPACE." So (as I understand it) it is required,
not optional, that an application's SGML parser expand entity and
character references in attribute value literals.
>Our current problem concerns the editing/display of Hebrew fragments in
>otherwise Latin-1 text. Using TEI as an example:
> <FOREIGN LANG="iw" REG="ℵ">A</FOREIGN>
>If you then apply a suffix (A/E terminology=affix) which replicates the
>value of REG on the screen (for example in parentheses after the element
>content, but still within the domain of FOREIGN), should the "ℵ"
>string be interpreted as a character entity reference and thus display
>the aleph character from position \345 in the font, or should it display
>the string "ℵ"?
I would expect the application to display whatever character is in
the given position in the font. (My octal is a bit rusty, let's see,
I think that must be hex E5, must be a proprietary font, since the
ISO character set 8859-8 has aleph at E0. Can't font makers ever learn
that it's better to implement standards than to ignore them entirely?
-C. M. Sperberg-McQueen
ACH / ACL / ALLC Text Encoding Initiative
University of Illinois at Chicago
[log in to unmask]