ISO/IEC JTC 1/SC 34N0629

ISO/IEC logo


Information Technology --
Document Description and Processing Languages

TITLE: Disposition of comments on SC34 N0622 - PDTR 9573-13: Maths and scientific character sets
SOURCE: Mr. Martin Bryan
PROJECT: PDTR 9573-13:2004 (type 3) 2nd Edition: Information technology -- SGML support facilities -- Techniques for using SGML -- Part 13: Public entity sets for SGML -- for mathematics and science
PROJECT EDITOR: Dr. David P. Carlisle
STATUS: Agreed disposition of comments
ACTION: Editor to create DTR text
DATE: 2005-05-23
DISTRIBUTION: SC34 and Liaisons
REFER TO: N0583r1 - 2005-02-10 - ISO 9573-13: Maths and scientific character sets
N0599b - 2005-02-24 - Ballot due 2005-05-24 PDTR 9573-13: Maths and scientific character sets
N0622 - 2005-05-20 - Summary of Voting on JTC 1/SC 34 N 599 - PDTR 9573-13: Maths and scientific character sets

Dr. James David Mason
(ISO/IEC JTC 1/SC 34 Chairman)
Y-12 National Security Complex
Bldg. 9113, M.S. 8208
Oak Ridge, TN 37831-8208 U.S.A.
Telephone: +1 865 574-6973
Facsimile: +1 865 574-1896
Network: [email protected]

Mr. G. Ken Holman
(ISO/IEC JTC 1/SC 34 Secretariat - Standards Council of Canada)
Crane Softwrights Ltd.
Box 266,
Telephone: +1 613 489-0999
Facsimile: +1 613 489-0995
Network: [email protected]

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.