SC22/WG20 N882R

 

Title:                Final disposition of comments of ballot results on PDAM-1 to ISO/IEC 14651:2001

 

Date:                2001-10-02

 

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

9 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 attached)

 

P” Members not supporting PDAM approval

2 (Ireland - see attached, Japan - see attached)      

 

“P” Members abstaining                   

1 (France)

“P” Members not voting                   

10 (Austria, Belgium, Brazil, China, Egypt, Finland, Norway, Romania, Slovenia, Ukraine)


Disposition of comments

 

1         Irish comments accompanying NO vote

 

 

IE 1.

 

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

order."

 

What was in the table was the transliteration order.

 

For the specification and discussion of this topic, see SC22/WG20

document N809R.

http://anubis.dkuug.dk/jtc1/sc22/open/..\WG20-2001-05\n809r-runic-order.pdf

 

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

template.

 

 

Accepted in principle.

 

 

 

2         Japanese comments

 

JP 1.

 

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

through LINK.

 

 

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.

 

JP 2.

 

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.

 

JP 3.

 

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.

 

3         USA comments accompanying YES vote

 

US 1.

 

General Comments

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

work.

 

Accepted in principle.

 

US 2.

 

Technical Comments

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

 

US 3.

 

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.

 

US 4.

 

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:

 

...

<SQUAREDCAP>

<FRACTION>

<MAX>

% Second-level weight assignments

<BASE>

...

In addition a collating symbol should be provided in the list of collating symbols:

...

collating-symbol <FRACTION>

collating-symbol <MAX>

...

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:

before

<U2473> "<S0032><S0030>";"<BASE><BASE>";"<CIRCLE><CIRCLE>";<U2473> % CIRCLED NUMBER TWENTY

after

<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.

 

US 5.

 

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

will become

<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:

<NEGATIVE>

<SANSSERIF>

<NEGSANSSERIF>

<ARABIC>

<EXTARABIC>

<ETHPC>

<NAGAR>

<BENGL>

<BENGALINUMERATOR>

<GURMU>

<GUJAR>

<ORIYA>

<TAMIL>

<TELGU>

<KNNDA>

<MALAY>

<THAII>

<LAAOO>

<BODKA>

<MYANM>

<KHMER>

<MONGL>

<CJKVS>

 

Accepted in principle.

 

------------- End of the official disposition of comments -----------

 

4         Kent Karlsson's unofficial Swedish comments (not received from the SC22 Secretariat [Sweden does not seem to currently be P-member]

 

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).

 

Accepted.

 

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

                weight.

 

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):

 

1. Scope

2. Conformance

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

                listed above.

 

                This is a more logical exposition order of the contents of 14651, without making any

                normative change.

 

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>.

 

Accepted.

 

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 -------