Title: Final disposition of comments of ballot results on PDAM-1 to ISO/IEC 14651:2001
Project: JTC 1.22.30.02.02
Source: Alain LaBonté, Project editor, on behalf of SC22/WG20
Status: Information required according to directives by SC22 Secretariat
References: SC22 N3242, N3318
Action: For national bodies consideration
SUMMARY OF VOTING AS PER SC22 N 3318
PDAM registration has been approved unanimouslyby 10 countries(Canada, Czech Republic, Denmark, Germany, Ireland, Japan, Republic of Korea, Netherlands, Russian Federation, UK, USA). 1 P-member abstained (France) and 10 P-members did not vote.
The following responses have been received on the subject of PDAM approval:
“P” Members supporting PDAM approval without comments
8 (Canada, Czech Republic, Denmark, Germany, Republic of Korea, Netherlands,
Russian Federation, UK, USA - see attached)
“P” Members supporting PDAM approval with comments
0 1 (USA - see
“P” Members not supporting PDAM approval
2 (Ireland - see attached, Japan - see attached)
“P” Members abstaining
“P” Members not voting
10 (Austria, Belgium, Brazil, China, Egypt, Finland, Norway, Romania, Slovenia, Ukraine)
Disposition of comments
NSAI Comments on SC 22 N 3242 – Concurrent PDAM Registration and PDAM Approval Ballot for PADAM 1 to ISO/IEC 14651
Due to the summer holidays, one of our experts was unable to report
back to us by the due date of 2001-09-01. While we voted positively
on 2001-08-30, Ireland would like to change our vote to DISAPPROVAL,
with the following technical comment:
In the tailorable template, the Runic script is ordered according to
Latin transliteration order. This produces ordering which does not
fully satisfy any user community. The Runes should be reordered to
the Futhark order in the tailorable template.
Note that the SC22/WG20 minutes are ambiguous as to what should have
been sent out for ballot:
"Runes were added after 14651 cut-off. Order of the Runes in N833 are
according to the preference of the ISO Runes project (Sweden). Other
people, such as Everson and Ken, disagree with the ISO project and
prefer the current usage on the web. Reason: academic work is done in
transliterations and the order is for the transliterated characters.
Everson's proposal is very close to the binary order in 10646
(Futhark) for all extensions in various countries. Transliterated
order would have to be a tailoring. Current draft table shows the
ISO Runes order.... Discussion about the merits of either ordering.
Decision that the order stays as in the table which is the Futhark
What was in the table was the transliteration order.
For the specification and discussion of this topic, see SC22/WG20
We believe that ambiguities in transliteration ordering will mean
that researchers in the Nordic countries and Britain and Ireland will
have to tailor ANYWAY to get a correct transliteration ordering.
Therefore the not-quite-perfect transliteration order in the
tailorable template serves little purpose. On the other hand, the
many non-researcher users of the Runes (who far outnumber the
researchers), universally prefer the Futhark order, and require no
tailoring for it. Since MOST users will not need to tailor, it seems
only logical that the Futhark order should be the order used in the
Accepted in principle.
Japan approves the PDAM registration of ISO/IEC 14651 PDAM1.
However, Japan disapproves the ISO/IEC 14651 itself. Japan will
change it position from disapproval to approval, if the following
3 security and procedural issues are resolved appropriately.
1) Japan concerns the security of the approved standards.
As agreed by ISO, every official documents published through Web
should be located under http://www.iso.ch and controlled by ITTF.
Also, since the common template table of ISO/IEC 14651 is
official publication of ISO and reader of the standard will not
care which committee provided the draft, it is not appropriate
to store a part of ISO standard onto SC or WG level Web page.
Therefore, Japan strongly suggests to store the actual contents
of Common Template Table of ISO/IEC 14651 onto
http://www.iso.ch/ittf. Japan has no concern if the actual
contents may be referred to from SC or WG level Web page
Accepted. The use of the SC site was not intended to be permanent. It goes without saying that the final AM1 will be on ITTF site.
2) By nature, contents of Web page may be changed frequently,
and it is impossible to confirm the integrity of the contents only
by URL. Even if the URL is identical, the contents may be revised
after publication or after cited date. Therefore, ISO standardized
the method for reference of Electronic document in ISO 690-2.
According to the standard, information of published/revised date
and cited date is mandatory to refer to a electronic document.
Following the heart of the standard, Japan would suggest to
add the published/revised date and cited date to the URL information
of the common template table.
The revised reference information might be follows.
ISO/IEC 14651 AM1 Annex A Common Template Table [online].
MONTH 2002 [cited DATE MONTH YEAR]. Available form
World Wide Web: <http://www.iso.ch/ittf/ISO14651_2002_TABLE1.TXT>.
Partly accepted. References prescribed by ISO is for standards, not parts of standards, and tables produced for ISO/IEC 14651 are uniquely identified and on ITTF secured site, the intent being that each version of the table will be frozen permanently under a unique name. If it is hacked by misintentioned people, ITTF is responsible for restoring its content to its original form from its archival backup.
3) Even if we provide high security of our Web, the contents of the
Web document may be changed by operation error or attack through
network by a virus program or a malicious person. In order to avoid
those unintentional technical change of standards, the cited date
information also be needed for other standard which refer to a
normative part of a standard which is available on the Web.
Therefore, Japan would suggest that guidelines to refer to
an online standard or a part of such a standard as normative reference
in any standard should be established by ISO/IEC JTC1/SC22
and every SC22 standard should write its cited date in addition to URL
if it refers to any document as normative.
Not accepted because it is not the competence of the ballot resolution meeting. What is needed is a guarantee that the content will not change.
GC1. Unicode 3.1 Repertoire. The industry has moved much more rapidly than anticipated to Unicode 3.1 /
ISO/IEC 10646, Part 2. Because of this there is a large implementation demand to extend the collation algorithm
to the full repertoire, including supplementary characters (those with code points between 0x10000 and
0x10FFFF). The earlier decisions to limit the repertoire handled by 14651 to the Unicode 3.0 repertoire have been
overtaken by events, and it is best to extend the repertoire as soon as possible. The US thus requests that the
repertoire covered in Table 1 be extended to cover the complete repertoire of Unicode 3.1.
The US is willing to supply draft weightings of these additional characters in an expanded CTT as a basis for this
Accepted in principle.
TC1. U+ 1670 CANADIAN SYLLABICS NGAI. Based on contributions from Canadian Syllabics experts consulted
by the US national body, the weight entry for this character needs to be moved so that U+1670 has a primary
weight after U+158D and before U+158E, as shown here:
<S158D> % CANADIAN SYLLABICS WEST-CREE RA
<S1670> % CANADIAN SYLLABICS NGAI
<S158E> % CANADIAN SYLLABICS NGAAI
Accepted in principle. Another change is required according to a Canadian expert consulted for this disposition of comments:
<157D> % CANADIAN SYLLABICS HK
<166F> % CANADIAN SYLLABICS QAI
<157E> % CANADIAN SYLLABICS QAAI
TC2. Runes. The Runic section should be reordered to be in Fuþark order. Ordering in Swedish transliteration
order is like ordering Ancient Greek by English transliteration order. Fuþark is the order of the original alphabet,
and provides a neutral ordering which is not tied to any particular locale Runic transliteration system. Fuþark
order is still widely used today by members of the general public using runes, and the expectation is that any
ordering of runes be in Fuþark order. Most people encountering runes will be dependent on default ordering
provided by their platforms, whereas experts will be in a better position to work with data tables with extra
columns for transliterations. The US supports the Irish position regarding the details of the Fuþark order that
should be in the CTT.
Accepted in principle. See IE 1.
Algorithmic Consistency Issues
While running extensive stress tests and corner-case tests against the CTT, a number of consistency problems
were encountered. The solutions to these problems described below have no effect on the normal use of
characters, but establish the formal correctness of the standard. A separate document will be provided to WG20
that will describe these consistency problems in detail. The following technical comments represent changes
required to fix these problems in the CTT.
TC3. Trailing Tertiaries. Add a tertiary symbol "<MAX>" which is always to be at the end of the tertiary symbol
weight list. Currently this would occur in the following position:
% Second-level weight assignments
In addition a collating symbol should be provided in the list of collating symbols:
In the weighting elements, certain characters (limited to a subset of those that at the tertiary level contain a
sequence of non-min tertiary weights) should have the second and subsequent tertiary weights replaced by this
new "<MAX>". Example:
<U2473> "<S0032><S0030>";"<BASE><BASE>";"<CIRCLE><CIRCLE>";<U2473> % CIRCLED NUMBER TWENTY
<U2473> "<S0032><S0030>";"<BASE><BASE>";"<CIRCLE><MAX>";<U2473> % CIRCLED NUMBER TWENTY
The precise list of characters that require this will be supplied in a separate document. The list will minimize the
number of characters required to fix the consistency problem. It is a short list -- a small subset of the compatibility
characters that have expansions.
Accepted in principle.
TC4. Modify handling of secondaries for Numerics. These are to be weighted consistent with the approach used
in other constructed secondaries (not involving an accent), such as in:
<U16AA> <S16A8>;"<BASE><VRNT1>";"<COMPAT><MIN>";<U16AA> % RUNIC LETTER AC A
Thus, the following example for a Mongolian digit
<U1811> <S0031>;<MONGL>;<MIN>;<U1811> % MONGOLIAN DIGIT ONE
<U1811> <S0031>;"<BASE><MONGL>";"<MIN><MIN>";<U1811> % MONGOLIAN DIGIT ONE
The list of numeric script secondary symbols to which this should be applied are the following:
Accepted in principle.
------------- End of the official disposition of comments -----------
SE 1. (MAJOR) Changes to clause 3 should be listed in the amendment:
* refer to ISO/IEC 10646-1:2000
* refer to ISO/IEC 10646-2:2001
Have a 'note' saying that those two together have the same repertoire and code point
assignments as Unicode 3.1. References to older editions of 10646 and its amendments
should be removed.
Accepted. In line with comment US 1. This will simplify the normative references which were in intermediary state. The note will be informative and useful indeed.
SE 2. Annex B: All of the tailoring examples should refer to the new table.
Accepted in principle. This was already done in PDAM 1 text balloted.
SE 3. (MAJOR) Annex A: The table should be extended to cover all of Unicode 3.1. If, during
the processing of this amendment to 14651, amendment 1 to 10646-1:2000 is
approved, consideration should be given to cover also those characters.
Accepted. In line with comment US 1. Normative references and text of annex A will be reviewed slightly.
SE 4. (MAJOR) The ordering of runic letters should follow the FUÞARK based ordering.
This is the ordering in which runic letters are traditionally presented. ABC-ordering
of the runic letters should be left to tailorings for specific purposes. Even though
ABC-ordering of runic letters may have been used during the late period of runic letter
usage, no evidence of this has been presented by runic experts, and would even so
be an influence of the then dominating latin script, not the order in which runes where
originally thought of. Further, when using runic letters as counters (for calendaric
calculations, at least), the FUÞARK order was used, much as ABC order of the
latin script is used for item list numbering.
Accepted in principle. In line with comments IE 1 and US 3.
SE 5. All Han based characters (CJK URO, CJK ext A, CJK ext B), should be ordered
together, in the order mentioned (currently ext A comes before the URO).
SE 6. (MAJOR) All <MIN> subweightings at level 3 that correspond to (pseudo-) combining
characters should be changed to <BLK> (possibly name-changed to <ACC>), in order
to make the weighting system more transparent to a human reader. (NOTE THAT
<MIN> should NOT be read as 'third level MINimum weight', but as 'third level weight
for MINuscule (or caseless) letter/digit'; <BLK> (=<ACC>) is the minimum third level
Not accepted. This would cause all kinds of difficulties to generate the table because it would create a weight which is lower than any weight that is currently in the table (and it would produce a problem in the implementation of the Unicode algorithm without changing the order [it does not address a technical problem]).
SE 7. US NB suggests to introduce a <MAX> weight; but since <MIN> is not minimum, the
name <MAX> would be misleading, making the reader think that <MIN> is mimumum.
Instead of <MAX> the name <LIG> is suggested.
Not accepted. MIN historically did not mean minimum but it is in fact now the minimum value. MAX is the maximum value.
SE 8. (MAJOR) Insert as a new annex E "Order-preserving subkey reduction"; moving the
bibliography to annex F. The text is attached at the end of these comments, and can
be obtained in electronic form from the Swedish NB. The kind of subkey reduction
described in (new) annex E is inherent in the "position" directive, and this annex
motivates why the "position" directive is sound. Further, annex E describe "high-level"
optimisations, not just implementation level optimisations.
Deferred to the next edition. This draft Annex E was not provided to the editor as of 2001-10-02.
SE 9. (MAJOR) The clauses in 14651 should be rearranged as follows (i.e. insert this as an
instruction to the editor, in the amendment text; as a basis for the next edition of 14651):
3. Normative references
4. Definitions and symbols [from current 4 and 5]
5. Common Template Table: formation and interpretation
[current 6.3, except 6.3.5 and 6.3.6]
6. Declaration of a delta [current 6.4]
7. String comparison [current 6.1 and 6.2]
8. Conditions for collation equivalence [from current 6.3.5 and 6.3.6]
Annex A - Common Template Table [and its name, current 6.5]
[and then the other annexes: B to F]
The subclause divisions are intended to be kept, even though the subclauses are not
This is a more logical exposition order of the contents of 14651, without making any
Not accepted for the moment. Please keep this comment for the CD ballot on the next edition. It does not belong in an amendment when text is not consolidated.
SE 10. The note for I 3 should use <BASE> instead of <BLANK>.
SE 11. (MAJOR) It has been suggested that the ordering after this amendment should not
be changed, INCLUDING that added characters are collated (via the CTT) at the end,
leaving better ordering of them to tailorings. Sweden does NOT support this LATTER
part of stability, since the CTT should give a good default ordering for characters
that are not of immediate concern to tailor.
Not accepted for the moment because it is irrelevant for the amendment. We however will have to address this stability problem for the next edition.
We agree that correctness is important but at some point correctness and
stability will converge.
[SE 12.] Annex E...
Not provided by Kent or Sweden as of 2001-10-02. Deferred to the next edition.
------------- End of this disposition of comments -------