---

Response to Japanese Comments

1. General

(1.1) The scope should make clear that this DTR is applicable to XML or not. In particular, will this TR provide entity declarations using SDATA entities?

Accepted:  SDATA entities will not need to be defined for the entities defined in this standard. The alternative proposal, based on using the character references, defined in clause 4.2 is designed to be applicable to XML, XHTML, MathML and other XML-based languages as well as in SGML and languages based on SGML such as HTML. This will be made clearer in the text.

(1.2) Since different entity sets assign different UCS code values to the same names, it may well be too late to resolve such conflicts.

Rejected: The purpose of this standard is to provide a standard set of entity names that UCS-aware teams can refer to as well. There has been close, and long, liaison with UCS experts to ensure that the names applied in this standard are widely accepted. This could be explained in the introduction.

2. Technical

(2.1) The first para in Section 4: This is not a standard but rather a TR.

Accepted: Text to be adjusted to make it clear that this is a technical report rather than a standard.

(2.2) The first para in 4.2:
First, there is no one-to-one relationship between characters and glyphs. Some characters in 10646 do not have glyphs. Other characters have different glyphs depending on combining characters.
Second, this subsection merely expands parsed entities by replacing them with numeric character references. Since this expansion is a standard behaviour of SGML or XML processors, we do not understand why this subsection is present.

Rejected: Great care has been taken to ensure that there is a clear mapping between the characters identifiable using the entities in this TR and the glyphs intended to be used to represent them. For this reason numeric character references have been clearly assigned to each of the entities to ensure that the correct character is selected from the UCS set. All selected characters have clearly defined glyphs, which are illustrated in the standard. None of the characters have combining characters associated with them.

The text of the first sentence of para 4.2 could be made more explicit by extending it to read:
Each character associated with an entity name defined in this technical report has a characteristic visual description known as a "glyph".

We note however, that para 4.2 proposes to use 5-digit hexadecimal numbers whereas UCS only enables the use of 4, 6 or 8 digit number. We recommend that a 6 digit number be used, with a leading zero.

Response to UK Comments

Needs to be aligned with SC2 changes to UCS character set.

Accepted.