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.
