ISO/ IEC JTC1/SC22 N2466

Date: Tue, 6 May 1997 16:59:37 -0400 (EDT)
From: "william c. rinehuls" <rinehuls@access.digex.net>
To: sc22docs@dkuug.dk
Subject: SC22 M2466 - Vote Summary of LB N2364 - CD 14651

____________________beginning of title page ___________________________
ISO/IEC JTC 1/SC22
Programming languages, their environments and system software interfaces
Secretariat: U.S.A.  (ANSI)



ISO/IEC JTC 1/SC22
N2466



May 1997



TITLE:             Summary of Voting on CD Approval for CD 14651 -
                   Information technology - International String
                   Ordering - Method for Comparing Character Strings
                   and Description of a Default Tailorable Ordering



SOURCE:            Secretariat, ISO/IEC JTC 1/SC22



WORK ITEM:         JTC 1.22.30.02.02



STATUS:            N/A



CROSS REFERENCE:   SC22 N2364



DOCUMENT TYPE:     Summary of Voting



ACTION:            To SC22 Member Bodies for information.

                   To WG20 for preparation of a Disposition of Comments
                   Report and a recommendation on the further processing
                   of the CD.



Address reply to:
ISO/IEC JTC 1/SC22 Secretariat
William C. Rinehuls
8457 Rushing Creek Court
Springfield, VA 22153  USA
Tel:  +1 (703) 912-9680
Fax:  +1 (703) 912-2973
email:  rinehuls@access.digex.net


________________end of title page; beginning of overall summary ________

                             SUMMARY OF VOTING ON

Letter Ballot Reference No:  SC22 N2364
Circulated by:               JTC 1/SC22
Circulation Date:            01-20-1997
Closing Date:                04-24-1997 


SUBJECT:  CD Approval for CD 14651 - Information technology 
          International String Ordering - Method for Comparing Character
          Strings and Description of a Default Tailorable Ordering


The following responses have been received on the subject of approval:


"P" Members supporting approval
      without comment                           10


"P" Members supporting approval
      with comment                               1


"P" Members not supporting approval              4



"P" Members abstaining                           2



"P" Members not voting                           7



"O" Members supporting approval
      without comment                            1



"O" Members not supporting approval              1



"O" Members abstaining                           1


Secretariat Action:

The comment accompanying the abstention vote from Germany was:  "There is
no national WG11 (sic) rapporteur."  The comments accompanying the
affirmative vote from Denmark; the comments accompanying the abstention
vote from the United Kingdom; and the comments accompanying the negative
votes from Austria, Israel, Japan, Netherlands, and USA are attached.

WG20 is requested to prepare a Disposition of Comments report and make a
recommendation on the further processing of the CD.

_______________end of overall summary; beginning of detail summary ___
                 ISO/IEC JTC1/SC22  LETTER BALLOT SUMMARY


PROJECT NO:    JTC 1.22.30.02.02

SUBJECT:  CD approval for CD 14651 - Information technology - International
          String Ordering - Method for Comparing Character Strings and
          Description of a Default Tailorable Ordering
          
Reference Document No:  N2364           Ballot Document No:  N2364
Circulation Date:   01-20-1997          Closing Date:  04-24-1997 
                                                              
Circulated To: SC22 P, O, L             Circulated By: Secretariat


                  SUMMARY OF VOTING AND COMMENTS RECEIVED

                      Approve  Disapprove  Abstain Comments   Not Voting
'P' Members

Australia               (X)      ( )         ( )       ( )       ( )
Austria                 ( )      (X)         ( )       (X)       ( )
Belgium                 ( )      ( )         ( )       ( )       (X)
Brazil                  ( )      ( )         ( )       ( )       (X)    
Canada                  ( )      ( )         ( )       ( )       (X)
China                   ( )      ( )         ( )       ( )       (X)
Czech Republic          (X)      ( )         ( )       ( )       ( )
Denmark                 (X)      ( )         ( )       (X)       ( )
Egypt                   ( )      ( )         ( )       ( )       (X)
Finland                 (X)      ( )         ( )       ( )       ( )
France                  (X)      ( )         ( )       ( )       ( )
Germany                 ( )      ( )         (X)       (X)       ( )
Ireland                 ( )      ( )         ( )       ( )       (X)
Japan                   ( )      (X)         ( )       (X)       ( )
Netherlands             ( )      (X)         ( )       (X)       ( )
Norway                  (X)      ( )         ( )       ( )       ( )
Romania                 (X)      ( )         ( )       ( )       ( )
Russian Federation      (X)      ( )         ( )       ( )       ( )
Slovenia                (X)      ( )         ( )       ( )       ( )
Sweden                  ( )      ( )         ( )       ( )       (X)
Switzerland             (X)      ( )         ( )       ( )       ( )
UK                      ( )      ( )         (X)       (X)       ( )
Ukraine                 (X)      ( )         ( )       ( )       ( )
USA                     ( )      (X)         ( )       (X)       ( )

'O' Members

Argentina               ( )      ( )         ( )       ( )       ( )
Bulgaria                ( )      ( )         ( )       ( )       ( )
Cuba                    ( )      ( )         ( )       ( )       ( )
Greece                  ( )      ( )         ( )       ( )       ( )
Hungary                 ( )      ( )         ( )       ( )       ( )
Iceland                 ( )      ( )         ( )       ( )       ( )
India                   ( )      ( )         ( )       ( )       ( )
Indonesia               ( )      ( )         ( )       ( )       ( )
Israel                  ( )      (X)         ( )       (X)       ( )
Italy                   ( )      ( )         ( )       ( )       ( )
Korea Republic          (X)      ( )         ( )       ( )       ( )
New Zealand             ( )      ( )         ( )       ( )       ( )
Poland                  ( )      ( )         ( )       ( )       ( )
Portugal                ( )      ( )         (X)       ( )       ( )
Singapore               ( )      ( )         ( )       ( )       ( )
Thailand                ( )      ( )         ( )       ( )       ( )
Turkey                  ( )      ( )         ( )       ( )       ( )
Yugoslavia              ( )      ( )         ( )       ( )       ( )

____end of detailed summary; beginning of Danish Comments Accompanying
Affirmative Vote__________________________

>From keld@dkuug.dk Tue Apr 29 15:57:22 1997

Here is the danish ballot on CD 14651:

Title: Comments on CD 14651 - International String Ordering

Source: Danish Standards Association

Date: 1997-04-29

Reference: SC22 N2364

The Danish ballot is: Yes, with general and technical comments

The comments are directed towards the english version of the text,
although the same comments can be done wrt. the French text.

1. The overall technical contents of CD 14652 is sound, and as agreed
by the working group, and thus we can accept the document as a CD.

General comments:

2. There is too much emphasis on the "binary sorting string" concept.
The concept of just comparing two strings should be catered for
overall in the document. Some places only sorting on binary prepared
strings are possible, to reach the functionality. Also there should be ample
warnings a number of places on the binary sorting string concept, as it
is culturally dependent, that is it is dependent on the sorting specification
used to produce the binary representation. Storing data in the precompiled
binary string representation should thus be recommended only for monocultural
environments, and that is actually environments that we should advise against,
having internationalization as our goal.

3. Formal description language, such as ISO 11404 or IDL of ISO 13788 (PCTE)
should be used in the specification of the APIs. The description of
the APIs lack a number of specifications now, including description of the
types of the parameters, and specifications of how to bind to programming
languages, that are inherent in the 11404 and 13788 specification languages.
We are willing to help rewriting the API sepcifications in light of this
comment.

4. We recommend that a thin binding method be used, as demonstrated
in other API papers of WG20. We can provide text for this, in conjunction
with text to address the problems mentioned in comment 3.

5. The APIs have 3 parameters, that should not occur in the API, because
all localisation should be done via the locale. These are the parameters
order_accents, order_case and sign_espace of the COMPCAR and CARABIN functions.

6. The LC_COLLATE specification in 14652 format should be readily useable
and referenceable, without need for retailoring. The different options,
as expressed by the parameters of the 3 parameters in our comment 5, should
be available as different LC_COLLATE specifications each with a well-defined
name.

7. The definitions in section 3 should be numbered and not ordered
alfabetically (in either English or French).

8. The definitions are too centered about a precompiled sorting string
concept. Terminology should also be applicable to comparisons on the
string encoding. Terms that should be useable with plain string comparisons
include: equivalence, ordering key, ordering subkey.

9. The technical specifications should be aligned with 14652. especially 
hexadecimal symbolix ellipses "..".

10. The names of the APIs should be less French-oriented.

11. The tables should use names established from the POSIX locale
work, such as ISO/IEC 9945-2 annex G names or 14652 names from the
repertoiremap, especially when not using <Uxxxx> names.

12. A number of scripts have not been ordered properly, such as hiragana and
katakana and thai.

13. A reversability function from binary sort strings to character strings
seems to be missing.

14. There are some spelling errors, and we suggest a spell-checker be used
for production of further documents.

Technical comments:

15. page 5: first paragraph: It is not always required to transform, for example
"4" into a number of strings, sometimes it is only necessary to transform
it into one string. Thus change "requires" to "may require" and "is hence"
to "may thus be".

16. Page 5, last paragraph and following prargraphs: Too much emphasis on the
precompiled sorted character
sting data type. This is not a general type as noted in our comment 2.

17. Page 8, Add after "Scandinavian" "and several other". This incudes languages
like Polish, Finnish, Hungarian, Turkish, and many others.

18. Page 14: "subprogramme" - rather use the word "function". All APIs in this
standard are functions. All references to "subprogrammess" should be 
changed to "functions" in the standard.

19. page 15, first paragraph: we recommend that only uppercase characters be
used in hexadecimal numbers, and this is also the specification in CD 14652.

20. Page 15, last paragraph: it seems like it is a requirement that a LC_COLLATE
specification, like the default, can be tailored on the fly. This is not
recommendable, as it would take quite some processing time, and thus delay
the processing considerable. On the fly tailoring should thus not be a
requirement.

21. Page 16, 5.1.1 last paragraph: use the name of the API (COMPCAR)
instead of the number "API 1".

22. Page 17: last paragraph: the names of the functions should be used for
the binding. Of cause the names of the functions may vary for the
different programming languages, but the names are more than "only
indicative".

23. Page 20: The COMPCAR function seems to miss a result value on
whether the first string was lexiographically less, equal or greater
than the second string. We propose the values -1, 0 and 1 for the three
possiblities, in line with current C practice. Also return values seems to
be missing for the other functions.

24. Page 21: It should not be normatively required that COMPCAR be equivalent
to CARABIN and COMPBIN. CARABIN produces output that is not necessary for
some use of COMPCAR.

25. Page 21, last paragraph: It should not be prescribed that there be
binary strings used for comparisons, in the COMPCAR function. Also the
"default" table mentioned here is the global locale, and not the 14651 default.
This should be clarified, maybe using "global" instead of "default".

26. Page 22: all parameters should be spelled out, and references to other
APIs when defining the parameters should be avoided.

27. Page 25 second paragraph: the default table cannot be used per se, as it
needs tailoring. See our comment 6 on how to solve this.

28. Page 27, first paragraph: this description is very oriented towards
the binary sort string. Descriptions also valid for COMPCAR method
without binary sort strings should be present. We would request a separate
descripti on how COMPCAR can be implemented, especially pointing out that only
comparison of the first (few) characters are necessary in many cases, and
that generating binary sort strings is typically not necessary.

29. Page 27: level 1: Some non-letters, for example Kana, may have more than
one character at the first level.

30. Page 27: note of 5.3.2.1: Combining accents may have ignore at level 1,
and then values at level 2. Should that not lead to full predictability?

31. Page 29: level one: Use the API names instead of "SUBPROGRAMME"

32. Page 29: what is the difference between level 2 and 4? In  traditional
locale invocation there is not that difference, but some other
difference. Maybe level 4 should always be required.

33. Page 31: COLL_WEIGHT_MAX is not a directive of 14652.

34. Page 31: Some scripts are not (yet) in IS 10646, for example the Yi and 
Canadian syllable scripts.

35. Page 31: We should assure that comments are allowable all the places used
here according to 14652, and possibly change 14652 to allow them.

36. Page 41-51: a number of the symbols defined here are also defined later.
Example <a8> defined on page 46 and page 79. This is not allowed according
to 14652 (giving a symbol two weights).

37. Page 111: (4) There needs to be a strong warning  that binary strings stored
cannot be used internationally for culturally correct sorting,
as they are stored in a localized form. Or we should simply advise against it.

38. Page 112: the text seems obsolete, as these concepts have been proven.

39. Page 115: Also list ISO/IEC 9945-2 POSIX shell and utilities, especially
annex G, as a source.

40. Page 118, paragraph 7: There is only a need for 4 levels, not 5. 

41. Page 118, paragraph 7:
Is it necessary to have an extra level for 10646 conformance level 3? Maybe
in some cases but not generally. When sorting the combining characters
per se, there is no need for a further level.

42. Page 119: paragraph 9: We thought this was proven not to be true. Or is this
some implementation guideline (which then should noted as such).

43. Page 120: Annex I should be explained further, especially how it fits into
the internationalization model.

_________________________end of Danish Comments _______________________
____________beginning of UK comments accompanying abstention vote ______ 

> N 2364 	ISO/IEC CD 14651
> 
> The UK ABSTAINS on this ballot, due to lack of participation in this area.
> The UK would however like to bring the following issues to the attention of
> SC 22 : 
> 
> - a tutorial on problems solved is inappropriate for an IS; either the
> document should be a TR or the tutorial moved to an appendix. 
> 
> - the statement on page 10 about information being obtainable from
> Alain LaBonte' is also inappropriate for a formal document.
> 
> 
> There are also a number of minor points:
> 
> - there are a disturbingly high number of elementary typographical
> errors (e.g.  p 18 'starings' (strings); 'compariosn', 'aat'; also mixed
> languages in chbin1, chbin2 heading).  On page 19 there are French
> quotation marks rather than English ones. 
> 
> - p 25 there is a reference to section 5.8, which does not exist.
> 
> - subprogramme is consistently spelled thus, although `subprogram' is
> the correct form in both US and UK (don't know about Canada, Australia
> etc).

______________________________end of UK comments ______________________
_____________beginning of Austrian comments accompanying negative _____

ON (the Austrian NB) votes NO on CD Ballot SC22 N2364
(CD 14651 - Information technology - International String
Ordering - Method for Comparing Character Strings and
Description of a Default Tailorable Ordering) with the
following comments:

(1) It seems doubtful (to say the least) that a reasonable
Default Ordering for all -- or even most -- of the languages
of the world can be found.  Consequently, there is reason to
doubt the usefulness of the proposed International Standard.

(2) The "Tutorial" contained in the Introduction should be
moved to an informative annex; it should not remain in the
main part of the document which would have to be considered
normative.

(3) Even though there is a "Tutorial", the proposed methods
do not seem to be well explained.  It could at least be
expected that one should be able to read and understand the
tables in Annex 1 without having to consult other sources.
For an example, see page 51 where a rather poor comment, in
itself encoded, supposedly explains the structure of the
following tables by cryptically stating:
    "% <Uxxxx> <Base>;<Accent>;<Case>;<Special>"
The sudden change of typeface on the same page seems equally
confusing und unmotivated (except possibly by line length).
Also, it seems that a more detailed description of a
possible practical implementation could prove helpful.

(4) The "Benchmark" in Annex 2 adds to the general confusion
by showing the "sorted" version to be (in excerpt):
    "vice-president's"
    "offices"
    "vice-presidents'"
    "offices"
The problem obviously lies in automatic line breaks and can
easily be corrected, but seems to raise the question whether
similar errors have been introduced in areas which are very
difficult -- if not impossible -- to check.  To mention the
most prominent example, some errors in Annex 1 might never
be found because this part of the document can hardly be
checked exhaustively.

(5) It is rather difficult to determine the necessity of
text that is not present.  ON does therefore not feel able
to decide on Annexes F, G, and H.

(6) The document has obviously been translated from French
to English, which would not be a problem if the process had
been completed.  For a counterexample see the description
of procedures chbin1 and chbin2 on page 18.  Also, the name
of procedure sign_espace (on page 19) seems to be partially
French.

(7) The document does not appear to have been spell-checked.
Some examples:
    p. 19:  "precedenceof" should be "precedence of"
    p.109:  "deafult" should be "default"
    p.114:  "standaredized" should be "standardized"

(8) Anticipating the answer that ON experts should actively
participate in the process of correction and development of
the document in question, ON states that expert resources
in this area are too limited at this time.  However, this
does not imply that any document can be accepted.  Sorry.

___________________ end of Austrian comments _______________________
________beginning of Japanese comments accompanying negative _______

Japan disapproves CD 14651 proposed in SC22 N2364.

The CD is not mature enough to proceed to DIS from view point of  
completeness as a JTC1 standard as follows.
- not precise enough tuned yet from technical view point,
- still not reaching a consensus on the expected ordering result.
- high dependency on ISO/IEC 14652 which is not in CD stage.  and
- style of the document does not meet the JTC1 requirement

Therefore, because of high dependency of this CD on ISO/IEC 14652, Japan  
requests to wait and synchronize the review and ballot of CD 14651 until  
CD 14652 is registered, or to change the scope of the standard to  
"ordering result" only and move API part to i18n API project.

Thus, Japan sees absolutely no reason why we need to proceed to DIS now.



Comment detail.

1. Style  (major editorial)
The CD is very different from the what ISO/JTC1 directive requires,  (and  
also different from the template provided by ITTF and many of JTC1  
standards)  For example, there are very high dependency on font selection  
(usage of bold, slant, point size variation and/or unnecessary type face  
mixture. are prohibited). The Definition clause need to have sub-clause  
for each terms, two groups of annex --one for normative and another for  
informative.  Review and rewrite all text according to ISO/JTC1 directive
and template supplied by ITTF.

2. Relation with ISO/IEC 14652. (General process)
The syntax and semantics of Annex 1 are not defined in this draft and are  
depending on ISO/IEC 14652 which is not available yet.  Synchronize the
project with ISO/IEC 14652 development -- wait for decision until CD 14652  
is available at least,  or, if it is not accepted, move related part of  
the ISO/IEC 14652 into this CD..

3. Tutorial (major editorial)
Heavy tutorial clause at the beginning is not a thing to do, move them to  
appropriate place and rewrite them to fit the new place.  In addition,  
there are many "information only" text in main clauses (such as clause  
5.3).  Remove them out from main (and mostly normative) part of the
standard, and place them (if really necessary) to appropriate related  
place(s).

4. Scope (major technical)
Describe what are this standard defines clearly and straight forward way.   
For example, change the word "a method" to much clear specific word (which  
is API).  Once above change is made, it may affect on the title of the
standard.  Also the word "Default Tailorable Ordering" does not have  
logical meaning.  One possibility of the new title would be "API with
default order for International string ordering".

Last part of 2nd bullet (on an order which is culturally---of that script)  
should be removed because "order which is acceptable culturally" is not a
scope of this standard.  This part should be re-written something like  
"The default order is aiming for easy understanding of non-casual user of  
the script, cultural correctness/acceptance is not a purpose of the
default order.  The correctness/acceptance by the casual (or native)  user
to be provided by tailoring by the user or as a country profile".

Rationale: Above has been an agreement on the project scope from the  
beginning.  There were many discussions of impracticalness of having a  
single default order which may satisfy all of cultures.  The conclusion
has been it is not practical to have such an ideal default order, and it
was said that "this is why tailoring is needed".  Japan, then, did not  
request culturally correctness for ordering.  Same story for French, since
French ordering is so sophisticated no outsider understand it easily,  
therefore, it is not practical to use true French order as international  
default order, it may causes mis-understanding of peoples of other
cultures. Such sophisticated ordering (such as French) can be  
satisfactorily supported by tailoring anyway.  (See clause 4.2.7 of DTR  
11017,  This IS is not i18n per 4.2.6 nor 4.2.4. This IS is aiming 4.2.7)

5.  Definitions (major technical)
5-1, Each definitions should have separated sub-clause number.
5-2. API:  Initial text of "for purpose of..... standard" is not
necessary. 
5-3. equivalence:  Too much, make it almost 1/3 by eliminating  
"informative" texts with in this definition. (for example: last 4 lines)
5-4. field, first order talken, fourth order talken level, level, second  
order talken, transformation, third order talken:  Eliminate "informative"  
explanations.
5-5. posthandling, prehandling : Those definition should be moved  to the  
related clause.
5-6  telephone-book-type transformation:  This term need not be defined  
in Definitions because it appears only once in Introduction (5th para.,  
Page 5).  Although Japan considers that the paragraph is understandable  
in itself, we propose to change the first sentence to:
   More generally, specific requirements exist for a kind of complex  
transformation 
  -- e.g. phonetic transformation adopted in some telephone-book systems 
because telephone-book ordering means differ from culture to culture, so,  
this wording may confuse the user.

6.  Conformance (major technical)
6-1.  Conformance clause(s) should come after the scope clause it should  
not be after the requirements clause.  The location of the conformance  
clause is inviting difficulty of understanding of each conformance levels  
clearly.

Reason (rationale) why conformance clause should be clause 2:
If requirement is simple and no leveling are employed, the conformance  
clause can be any place in theory. Note that ISO/IEC directive part-3  
does not require "conformance clause" even.  However, in case of ISO/IEC  
CD 14651, the condition is different, it should be clause 2.
Since 14651 is a very complicated multilevel standard. the scope clause  
can not cover all what "scope' clause should say.  The conformance, in  
particular, the clean and clear "levels" descriptions are acting, in
reality, as a sub-scope clauses as well as real conformance descriptions.   
If it does not come after "scope" clause, it is almost impossible for the  
user of the standard to understand "what are defined in this standard and  
how to read the standard efficiently and accurately".
6-2,  Conformance clause should have exact pointer(s) for the conformance  
requirement (clause and sub-clause numbers).  Umbrella conformance for  
buried requirements with in main clauses (like this CD) should not be
used.   (Current CD is too unkindly for reader)
6-3.  In case of leveled conformance, provide a sub-clause to explain  
what those levels are much straight way.  (Too many indirect explanation  
now).
6-3-1.  Conformance level-1 should be defined as "Generic API only.    And  
should not make some of the parameters as "option".  The option causes  
in-compatibility problems between conforming level-1 APIs.   Further  
define two options (not parameter option s), one for COMPCAR and another
for COMPBIN + CARABIN.
6-3-2  Conformance level-2 should be defined and stated as "Generic API  
and table format"
6-3-3  Conformance level-3:  Change prehandling to requirement for string
input as normative.  Thus prehandling is out of scope of this standard  
(remove 5.1.2 at least).   Then, change the description of this
conformance level accordantly.  By the way, in current text, normative
clause (5.1.2) is reefers informative annex. This is prohibited practice.
6-3-4  Conformance level-4.    Remove the word "possibility". then  
resultant might be "Add API an access method for specific table.
6-4.  Add a concept of conformance for "ordering result only"
6-5  Add a method to specify partial conformance of ordering result, for  
example, a method to state "every thing but Japanese repertoire are  
conforming this default order and Japanese repertoire are per JIS" would  
be a real life use of this standard.  (as one of sub-set of the ordering
result only conformance)
6-6,  Add a method to swap the order of th
0a+e scripts, but still the orders within each scripts are conforming
default order.
6-7,  Add a method to state only selected scripts in comment 6-6 are  
conforming the default order.
6-8,  Maintain compatibility with POSIX and C.  Providing independent  
conformance level may be one of the choice to respond for this comment. .
6-9,  Remove all of "best guess" dependency.  Write exactly what is needed.   For example, there is no description what "default order" is.  There is default table and API (and conformance levels), so best guess may be use the "default table" with the API
s.


7. Requirements (major technical)
7-1.  There are many options in one conformance level, those should be  
another levels of conformance if those are really necessary.
7-2.  The "Toggle" mechanism, which is realized by parameters  
"order_accent", "order_case" and "sign_escape", should be removed  
because:
1) it contradicts with the concept of the locale mechanism -- it allows an  
ordering regardless of the ordering table defined as a locale,
2) the concepts of "case" and "accents" are specific to some scripts and  
they are not defined in this draft where these script-dependent concepts  
have been resolved into universal rules in tables.
Instead of the current "Toggle" mechanism, Japan proposes to reconsider  
the specification of ordering tables, which will be defined in ISO/IEC  
14652, so as to enable variants of the default table be defined more  
flexibly -- for example, by introducing som e preprocessing elements
        #define ...
        #ifdef ...
        #include ...
etc.

7-3.  table
To specify a name of an ordering table in COMPCAR and CARABIN as a  
parameter "table" will put a heavy burden on implementations.  At runtime  
the processes COMPCAR and CARABIN should check every time whenever the  
table is changed from that of the previous call and/or the table should  
be compiled.
There are two alternatives to this problem:
1) to remove the parameter "table" from the two processes and define a  
new process "set_collating_table" which has a parameter "table",
2) to define a new process "open_table" which has an input parameter  
"table" and returns a pointer to a protected structure derived from that  
"table" while the parameter "table" in the two process is changed to  
"table_pointer".
7-4  "chbin1" and "chbin2" in COMPCAR are not necessary. Further more,  
options within an API specification does not make any sense at all.
7-5. The whole contents of 5.3 should be removed or put into an
informative annex because those contents are to be defined in ISO/IEC  
14652 in the current framework.
7-6. Add text for the case where characters are not encoded in ISO/IEC  
10646. Some character set, e.g. ISO 6937 are not in ISO/IEC 10646, and  
some do not have conversion table (or same character names) with ISO/IEC  
10646 (yet).

8. Data table (such as Annex A) (major technical)
8-1.  Japan confirms a principle of default order table as:
- The default order is non-native user friendly (easy to understand,  
simple rule, less exceptions)
- Cultural correctness for the native user of the script should be done  
by tailoring.  APIs and data format should have enough room for the  
necessary tailoring.
- Therefore, cultural correctness of the default order is not a goal of  
this standard.  Based on the principle above, Japanese proposal on
Japanese scripts are not correct for Japanese view, however, it is easy
for the people who are not familiar with Japanese scripts.
8-2 Collation for HIRAGANA and KATAKANA
Japan proposes to add a set of collating rules for HIRAGANA and KATAKANA  
attached..

The order defined in Attachment is different from one defined in JIS X
4061 which was published in February 1997.  The main differences in  
handling of a prolonged sound mark <U30FC>. Roughly speaking, JIS X 4061  
replaces the prolonged sound mark with the vowel of the most recent
letter,  while Attachment neglects the prolonged sound mark at first in  
the same way as a hyphen.
The second difference is handling of the iteration marks <U309D>, <U309E>,  
<U30FD>, <U30FE>.  Roughly speaking, JIS X 4061 replaces the iteration  
marks with the most recent KANA letter, while Attachment handles the  
iteration marks as they are.

The reasons for proposing Attachment are as follows:
  1) JIS X 4061 cannot be realized by LC_COLLATE representation
  unless some rules using regular expression, which will put a heavy
  burden on implementations, are introduced,

  2) ordering results of JIS X 4061 are hard to understand for
  foreigners without knowledge of how letter sequences are
  pronounced -- it is not cross-culture friendly,

  3) ordering results of Attachment are easy to understand for
  foreigners without knowledge of pronunciation of letter sequences
  and even in Japan, a number of encyclopedia order their items in
  the same way as Attachment does -- it is cross-culture friendly,

8-3  Consideration on Compatibility characters of ISO/IEC 10646.  
Consideration on the compatibility characters are missing.  At least,  
following are needed. 8-3-1  UFF00-FF9F, FFE0-FFE8
Handle those characters as same as equivalent characters in A-zone.
8-3-2  F900-FA0D, FA10, FA12, FA15-FA1E, FA20, FA22, FA25, FA26,  
FA2A-FA2D of ISO/IEC 10646-1  Handle those characters as same as
equivalent characters in I-zone.
8-4  FA0E, FA0F, FA11, FA13, FA14, FA1F, FA21, FA23, FA24, FA27-FA29 of 
ISO/IEC 10646-1 and future addition of CJK ideographs (ext-A and B).
Merge them with I-zone characters with defined rule. Provide informative  
annex which describe the rule (radical, number of the stroke and so  
on.....)
8-5  Character combination type symbols.
For those characters which are made up combination of two or more  
Japanese characters such as 3300-336F, Handle those as if those are  
string of independent characters.
8-6. Symbols of character(s) and symbol(s)
Symbols with character(s) should be handled one of following methods. 
a) Character(s) and symbol(s) like "short form" of normal writing such  as
2480 which is looked like "( 13 )".   Split the symbol as if it is a  
normal string.
b) Character(s) and symbols can not split into one unambiguous sequence  
such as 2470 which the circle can be either before or after character 17.
Handle as if it is a special form of the character(s) part of the symbol.
8-7.  Symbols for making combining sequence such as 20E0.
Follow the rule proposed at 8-6 above, the process might be different  
from the method for combining sequences.
8-8. Japan expect many countries have same kinds of comments above.   
Japan request, therefore, confirmation of specific to the data table to  
be circulated to all JTC1 member countries (not only SC22 p-member) for  
review.

9. Other comments
Japan recognizes many editorial issues as well as technical issues which  
are not on this ballot comment, too many major technical comments (and  
may be more to expect) does not give us a time to scan all of them.    
Japan thinks the minor editorial comment are unnecessary components of  
this ballot comments because of un-matureness of the CD 14651.
Anyway, the text should be rewritten totally for full acceptance of the  
technical comments.


 
-------  ATTACHMENT ---------

%level 1
<kn-dot>
<kn-prolong>
<kn-a>
<kn-i>
<kn-u>
<kn-e>
<kn-o>
<kn-ka>
<kn-ki>
<kn-ku>
<kn-ke>
<kn-ko>
<kn-sa>
<kn-si>
<kn-su>
<kn-se>
<kn-so>
<kn-ta>
<kn-ti>
<kn-tu>
<kn-te>
<kn-to>
<kn-na>
<kn-ni>
<kn-nu>
<kn-ne>
<kn-no>
<kn-ha>
<kn-hi>
<kn-hu>
<kn-he>
<kn-ho>
<kn-ma>
<kn-mi>
<kn-mu>
<kn-me>
<kn-mo>
<kn-ya>
<kn-yu>
<kn-yo>
<kn-ra>
<kn-ri>
<kn-ru>
<kn-re>
<kn-ro>
<kn-wa>
<kn-wi>
<kn-we>
<kn-wo>
<kn-n>
<kn-cmb-voice>
<kn-cmb-semivoice>
<kn-voice>
<kn-semivoice>
<kn-iter>

%level 2
<kn-HIRA>
<kn-KATA>

%level 3
<kn-SMALL>
<kn-SMALL-HF>           % for Table 122
<kn-NORMAL>
<kn-NORMAL-HF>          % for Table 122
<kn-VOICED>
<kn-SEMIVOICED>

% abbreviations in comments -- UCS Name:
%       HIRAkn -- HIRAGANA LETTER
%       KATAkn -- KATAKANA LETTER
%       hfwd   -- HALFWIDTH
%       voice  -- HIRAGANA-KATAKANA VOICED SOUND MARK
%       semi-voice -- HIRAGANA-kATAKANA SEMI-VOICED SOUND MARK
%       iter   -- ITERATION
%       comb    -- COMBINING
%       prolong -- KATAKANA-HIRAGANA PROLONGED SOUND MARK
%
<U3041> <kn-a>;<kn-HIRA>;<kn-SMALL>;<IGNORE> % HIRAkn  SMALL A
<U3042> <kn-a>;<kn-HIRA>;<kn-NORAML>;<IGNORE> % HIRAkn  A
<U30A1> <kn-a>;<kn-KATA>;<kn-SMALL>;<IGNORE> % KATAkn  SMALL A
<UFF67> <kn-a>;<kn-KATA>;<kn-SMALL-HF>;<IGNORE> % hfwd KATAkn  SMALL A
<U30A2> <kn-a>;<kn-KATA>;<kn-NORMAL>;<IGNORE> % KATAkn  A
<UFF71> <kn-a>;<kn-KATA>;<kn-NORMAL-HF>;<IGNORE> % hfwd KATAkn  A
%
<U3043> <kn-i>;<kn-HIRA>;<kn-SMALL>;<IGNORE> % HIRAkn  SMALL I
<U3044> <kn-i>;<kn-HIRA>;<kn-NORAML>;<IGNORE> % HIRAkn  I
<U30A3> <kn-i>;<kn-KATA>;<kn-SMALL>;<IGNORE> % KATAkn  SMALL I
<UFF68> <kn-i>;<kn-KATA>;<kn-SMALL-HF>;<IGNORE> % hfwd KATAkn  SMALL I
<U30A4> <kn-i>;<kn-KATA>;<kn-NORMAL>;<IGNORE> % KATAkn  I
<UFF72> <kn-i>;<kn-KATA>;<kn-NORMAL-HF>;<IGNORE> % hfwd KATAkn  I
%
<U3045> <kn-u>;<kn-HIRA>;<kn-SMALL>;<IGNORE> % HIRAkn  SMALL U
<U3046> <kn-u>;<kn-HIRA>;<kn-NORAML>;<IGNORE> % HIRAkn  U
<U3094> <kn-u>;<kn-HIRA>;<kn-VOICED>;<IGNORE> % HIRAkn  VU
<U30A5> <kn-u>;<kn-KATA>;<kn-SMALL>;<IGNORE> % KATAkn  SMALL U
<UFF69> <kn-u>;<kn-KATA>;<kn-SMALL-HF>;<IGNORE> % hfwd KATAkn  SMALL U
<U30A6> <kn-u>;<kn-KATA>;<kn-NORMAL>;<IGNORE> % KATAkn  U
<UFF73> <kn-u>;<kn-KATA>;<kn-NORMAL-HF>;<IGNORE> % hfwd KATAkn  U
<U30F4> <kn-u>;<kn-KATA>;<kn-VOICED>;<IGNORE> % KATAkn  VU
%
<U3047> <kn-e>;<kn-HIRA>;<kn-SMALL>;<IGNORE> % HIRAkn  SMALL E
<U3048> <kn-e>;<kn-HIRA>;<kn-NORAML>;<IGNORE> % HIRAkn  E
<U30A7> <kn-e>;<kn-KATA>;<kn-SMALL>;<IGNORE> % KATAkn  SMALL E
<UFF6A> <kn-e>;<kn-KATA>;<kn-SMALL-HF>;<IGNORE> % hfwd KATAkn  SMALL E
<U30A8> <kn-e>;<kn-KATA>;<kn-NORMAL>;<IGNORE> % KATAkn  E
<UFF74> <kn-e>;<kn-KATA>;<kn-NORMAL-HF>;<IGNORE> % hfwd KATAkn  E
%
<U3049> <kn-o>;<kn-HIRA>;<kn-SMALL>;<IGNORE> % HIRAkn  SMALL O
<U304A> <kn-o>;<kn-HIRA>;<kn-NORAML>;<IGNORE> % HIRAkn  O
<U30A9> <kn-o>;<kn-KATA>;<kn-SMALL>;<IGNORE> % KATAkn  SMALL O
<UFF6B> <kn-o>;<kn-KATA>;<kn-SMALL-HF>;<IGNORE> % hfwd KATAkn  SMALL O
<U30AA> <kn-o>;<kn-KATA>;<kn-NORMAL>;<IGNORE> % KATAkn  O
<UFF75> <kn-o>;<kn-KATA>;<kn-NORMAL-HF>;<IGNORE> % hfwd KATAkn  O
%
<U304B> <kn-ka>;<kn-HIRA>;<kn-NORMAL>;<IGNORE> % HIRAkn  KA
<U304C> <kn-ka>;<kn-HIRA>;<kn-VOICED>;<IGNORE> % HIRAkn  GA
<U30F5> <kn-ka>;<kn-KATA>;<kn-SMALL>;<IGNORE> % KATAkn  SMALL KA
<U30AB> <kn-ka>;<kn-KATA>;<kn-NORMAL>;<IGNORE> % KATAkn  KA
<UFF76> <kn-ka>;<kn-KATA>;<kn-NORMAL-HF>;<IGNORE> % hfwd KATAkn  KA
<U30AC> <kn-ka>;<kn-KATA>;<kn-VOICED>;<IGNORE> % KATAkn  GA
%
<U304D> <kn-ki>;<kn-HIRA>;<kn-NORMAL>;<IGNORE> % HIRAkn  KI
<U304E> <kn-ki>;<kn-HIRA>;<kn-VOICED>;<IGNORE> % HIRAkn  GI
<U30AD> <kn-ki>;<kn-KATA>;<kn-NORMAL>;<IGNORE> % KATAkn  KI
<UFF77> <kn-ki>;<kn-KATA>;<kn-NORMAL-HF>;<IGNORE> % hfwd KATAkn  KI
<U30AE> <kn-ki>;<kn-KATA>;<kn-VOICED>;<IGNORE> % KATAkn  GI
%
<U304F> <kn-ku>;<kn-HIRA>;<kn-NORMAL>;<IGNORE> % HIRAkn  KU
<U3050> <kn-ku>;<kn-HIRA>;<kn-VOICED>;<IGNORE> % HIRAkn  GU
<U30AF> <kn-ku>;<kn-KATA>;<kn-NORMAL>;<IGNORE> % KATAkn  KU
<UFF78> <kn-ku>;<kn-KATA>;<kn-NORMAL-HF>;<IGNORE> % hfwd KATAkn  KU
<U30B0> <kn-ku>;<kn-KATA>;<kn-VOICED>;<IGNORE> % KATAkn  GU
%
<U3051> <kn-ke>;<kn-HIRA>;<kn-NORMAL>;<IGNORE> % HIRAkn  KE
<U3052> <kn-ke>;<kn-HIRA>;<kn-VOICED>;<IGNORE> % HIRAkn  GE
<U30F6> <kn-ke>;<kn-KATA>;<kn-SMALL>;<IGNORE> % KATAkn  SMALL KE
<U30B1> <kn-ke>;<kn-KATA>;<kn-NORMAL>;<IGNORE> % KATAkn  KE
<UFF79> <kn-ke>;<kn-KATA>;<kn-NORMAL-HF>;<IGNORE> % hfwd KATAkn  KE
<U30B2> <kn-ke>;<kn-KATA>;<kn-VOICED>;<IGNORE> % KATAkn  SMALL GE
%
<U3053> <kn-ko>;<kn-HIRA>;<kn-NORMAL>;<IGNORE> % HIRAkn  KO
<U3054> <kn-ko>;<kn-HIRA>;<kn-VOICED>;<IGNORE> % HIRAkn  GO
<U30B3> <kn-ko>;<kn-KATA>;<kn-NORMAL>;<IGNORE> % KATAkn  KO
<UFF7A> <kn-ko>;<kn-KATA>;<kn-NORMAL-HF>;<IGNORE> % hfwd KATAkn  KO
<U30B4> <kn-ko>;<kn-KATA>;<kn-VOICED>;<IGNORE> % KATAkn  GO
%
<U3055> <kn-sa>;<kn-HIRA>;<kn-NORMAL>;<IGNORE> % HIRAkn  SA
<U3056> <kn-sa>;<kn-HIRA>;<kn-VOICED>;<IGNORE> % HIRAkn  ZA
<U30B5> <kn-sa>;<kn-KATA>;<kn-NORMAL>;<IGNORE> % KATAkn  SA
<UFF7B> <kn-sa>;<kn-KATA>;<kn-NORMAL-HF>;<IGNORE> % hfwd KATAkn  SA
<U30B6> <kn-sa>;<kn-KATA>;<kn-VOICED>;<IGNORE> % KATAkn  ZA
%
<U3057> <kn-si>;<kn-HIRA>;<kn-NORMAL>;<IGNORE> % HIRAkn  SI
<U3058> <kn-si>;<kn-HIRA>;<kn-VOICED>;<IGNORE> % HIRAkn  ZI
<U30B7> <kn-si>;<kn-KATA>;<kn-NORMAL>;<IGNORE> % KATAkn  SI
<UFF7C> <kn-si>;<kn-KATA>;<kn-NORMAL-HF>;<IGNORE> % hfwd KATAkn  SI
<U30B8> <kn-si>;<kn-KATA>;<kn-VOICED>;<IGNORE> % KATAkn  ZI
%
<U3059> <kn-su>;<kn-HIRA>;<kn-NORMAL>;<IGNORE> % HIRAkn  SU
<U305A> <kn-su>;<kn-HIRA>;<kn-VOICED>;<IGNORE> % HIRAkn  ZU
<U30B9> <kn-su>;<kn-KATA>;<kn-NORMAL>;<IGNORE> % KATAkn  SU
<UFF7D> <kn-su>;<kn-KATA>;<kn-NORMAL-HF>;<IGNORE> % hfwd KATAkn  SU
<U30BA> <kn-su>;<kn-KATA>;<kn-VOICED>;<IGNORE> % KATAkn  ZU
%
<U305B> <kn-se>;<kn-HIRA>;<kn-NORMAL>;<IGNORE> % HIRAkn  SE
<U305C> <kn-se>;<kn-HIRA>;<kn-VOICED>;<IGNORE> % HIRAkn  ZE
<U30BB> <kn-se>;<kn-KATA>;<kn-NORMAL>;<IGNORE> % KATAkn  SE
<UFF7E> <kn-se>;<kn-KATA>;<kn-NORMAL-HF>;<IGNORE> % hfwd KATAkn  SE
<U30BC> <kn-se>;<kn-KATA>;<kn-VOICED>;<IGNORE> % KATAkn  ZE
%
<U305D> <kn-so>;<kn-HIRA>;<kn-NORMAL>;<IGNORE> % HIRAkn  SO
<U305E> <kn-so>;<kn-HIRA>;<kn-VOICED>;<IGNORE> % HIRAkn  ZO
<U30BD> <kn-so>;<kn-KATA>;<kn-NORMAL>;<IGNORE> % KATAkn  SO
<UFF7F> <kn-so>;<kn-KATA>;<kn-NORMAL-HF>;<IGNORE> % hfwd KATAkn  SO
<U30BE> <kn-so>;<kn-KATA>;<kn-VOICED>;<IGNORE> % KATAkn  ZO
%
<U305F> <kn-ta>;<kn-HIRA>;<kn-NORMAL>;<IGNORE> % HIRAkn  TA
<U3060> <kn-ta>;<kn-HIRA>;<kn-VOICED>;<IGNORE> % HIRAkn  DA
<U30BF> <kn-ta>;<kn-KATA>;<kn-NORMAL>;<IGNORE> % KATAkn  TA
<UFF80> <kn-ta>;<kn-KATA>;<kn-NORMAL-HF>;<IGNORE> % hfwd KATAkn  TA
<U30C0> <kn-ta>;<kn-KATA>;<kn-VOICED>;<IGNORE> % KATAkn  DA
%
<U3061> <kn-ti>;<kn-HIRA>;<kn-NORMAL>;<IGNORE> % HIRAkn  TI
<U3062> <kn-ti>;<kn-HIRA>;<kn-VOICED>;<IGNORE> % HIRAkn  DI
<U30C1> <kn-ti>;<kn-KATA>;<kn-NORMAL>;<IGNORE> % KATAkn  TI
<UFF81> <kn-ti>;<kn-KATA>;<kn-NORMAL-HF>;<IGNORE> % hfwd KATAkn  TI
<U30C2> <kn-ti>;<kn-KATA>;<kn-VOICED>;<IGNORE> % KATAkn  DI
%
<U3063> <kn-tu>;<kn-HIRA>;<kn-SMALL>;<IGNORE> % HIRAkn  SMALL TU
<U3064> <kn-tu>;<kn-HIRA>;<kn-NORMAL>;<IGNORE> % HIRAkn  TU
<U3065> <kn-tu>;<kn-HIRA>;<kn-VOICED>;<IGNORE> % HIRAkn  DU
<U30C3> <kn-tu>;<kn-KATA>;<kn-SMALL>;<IGNORE> % KATAkn  SMALL TU
<UFF6F> <kn-tu>;<kn-KATA>;<kn-SMAL-HFL>;<IGNORE> % hfwd KATAkn  SMALL TU
<U30C4> <kn-tu>;<kn-KATA>;<kn-NORMAL>;<IGNORE> % KATAkn  TU
<UFF82> <kn-tu>;<kn-KATA>;<kn-NORMAL-HF>;<IGNORE> % hfwd KATAkn  TU
<U30C5> <kn-tu>;<kn-KATA>;<kn-VOICED>;<IGNORE> % KATAkn  DU
%
<U3066> <kn-te>;<kn-HIRA>;<kn-NORMAL>;<IGNORE> % HIRAkn  TE
<U3067> <kn-te>;<kn-HIRA>;<kn-VOICED>;<IGNORE> % HIRAkn  DE
<U30C6> <kn-te>;<kn-KATA>;<kn-NORMAL>;<IGNORE> % KATAkn  TE
<UFF83> <kn-te>;<kn-KATA>;<kn-NORMAL-HF>;<IGNORE> % hfwd KATAkn  TE
<U30C7> <kn-te>;<kn-KATA>;<kn-VOICED>;<IGNORE> % KATAkn  DE
%
<U3068> <kn-to>;<kn-HIRA>;<kn-NORMAL>;<IGNORE> % HIRAkn  TO
<U3069> <kn-to>;<kn-HIRA>;<kn-VOICED>;<IGNORE> % HIRAkn  DO
<U30C8> <kn-to>;<kn-KATA>;<kn-NORMAL>;<IGNORE> % KATAkn  TO
<UFF84> <kn-to>;<kn-KATA>;<kn-NORMAL-HF>;<IGNORE> % hfwd KATAkn  TO
<U30C9> <kn-to>;<kn-KATA>;<kn-VOICED>;<IGNORE> % KATAkn  DO
%
<U306A> <kn-na>;<kn-HIRA>;<kn-NORMAL>;<IGNORE> % HIRAkn  NA
<U30CA> <kn-na>;<kn-KATA>;<kn-NORMAL>;<IGNORE> % KATAkn  NA
<UFF85> <kn-na>;<kn-KATA>;<kn-NORMAL-HF>;<IGNORE> % hfwd KATAkn  NA
%
<U306B> <kn-ni>;<kn-HIRA>;<kn-NORMAL>;<IGNORE> % HIRAkn  NI
<U30CB> <kn-ni>;<kn-KATA>;<kn-NORMAL>;<IGNORE> % KATAkn  NI
<UFF86> <kn-ni>;<kn-KATA>;<kn-NORMAL-HF>;<IGNORE> % hfwd KATAkn  NI
%
<U306C> <kn-nu>;<kn-HIRA>;<kn-NORMAL>;<IGNORE> % HIRAkn  NU
<U30CC> <kn-nu>;<kn-KATA>;<kn-NORMAL>;<IGNORE> % KATAkn  NU
<UFF87> <kn-nu>;<kn-KATA>;<kn-NORMAL-HF>;<IGNORE> % hfwd KATAkn  NU
%
<U306D> <kn-ne>;<kn-HIRA>;<kn-NORMAL>;<IGNORE> % HIRAkn  NE
<U30CD> <kn-ne>;<kn-KATA>;<kn-NORMAL>;<IGNORE> % KATAkn  NE
<UFF88> <kn-ne>;<kn-KATA>;<kn-NORMAL-HF>;<IGNORE> % hfwd KATAkn  NE
%
<U306E> <kn-no>;<kn-HIRA>;<kn-NORMAL>;<IGNORE> % HIRAkn  NO
<U30CE> <kn-no>;<kn-KATA>;<kn-NORMAL>;<IGNORE> % KATAkn  NO
<UFF89> <kn-no>;<kn-KATA>;<kn-NORMAL-HF>;<IGNORE> % hfwd KATAkn  NO
%
<U306F> <kn-ha>;<kn-HIRA>;<kn-NORMAL>;<IGNORE> % HIRAkn  HA
<U3070> <kn-ha>;<kn-HIRA>;<kn-VOICED>;<IGNORE> % HIRAkn  BA
<U3071> <kn-ha>;<kn-HIRA>;<kn-SEMIVOICED>;<IGNORE> % HIRAkn  PA
<U30CF> <kn-ha>;<kn-KATA>;<kn-NORMAL>;<IGNORE> % KATAkn  HA
<UFF8A> <kn-ha>;<kn-KATA>;<kn-NORMAL-HF>;<IGNORE> % hfwd KATAkn  HA
<U30D0> <kn-ha>;<kn-KATA>;<kn-VOICED>;<IGNORE> % KATAkn  BA
<U30D1> <kn-ha>;<kn-KATA>;<kn-SEMIVOICED>;<IGNORE> % KATAkn  PA
%
<U3072> <kn-hi>;<kn-HIRA>;<kn-NORMAL>;<IGNORE> % HIRAkn  HI
<U3073> <kn-hi>;<kn-HIRA>;<kn-VOICED>;<IGNORE> % HIRAkn  BI
<U3074> <kn-hi>;<kn-HIRA>;<kn-SEMIVOICED>;<IGNORE> % HIRAkn  PI
<U30D2> <kn-hi>;<kn-KATA>;<kn-NORMAL>;<IGNORE> % KATAkn  HI
<UFF8B> <kn-hi>;<kn-KATA>;<kn-NORMAL-HF>;<IGNORE> % hfwd KATAkn  HI
<U30D3> <kn-hi>;<kn-KATA>;<kn-VOICED>;<IGNORE> % KATAkn  BI
<U30D4> <kn-hi>;<kn-KATA>;<kn-SEMIVOICED>;<IGNORE> % KATAkn  PI
%
<U3075> <kn-hu>;<kn-HIRA>;<kn-NORMAL>;<IGNORE> % HIRAkn  HU
<U3076> <kn-hu>;<kn-HIRA>;<kn-VOICED>;<IGNORE> % HIRAkn  BU
<U3077> <kn-hu>;<kn-HIRA>;<kn-SEMIVOICED>;<IGNORE> % HIRAkn  PU
<U30D5> <kn-hu>;<kn-KATA>;<kn-NORMAL>;<IGNORE> % KATAkn  HU
<UFF8C> <kn-hu>;<kn-KATA>;<kn-NORMAL-HF>;<IGNORE> % hfwd KATAkn  HU
<U30D6> <kn-hu>;<kn-KATA>;<kn-VOICED>;<IGNORE> % KATAkn  BU
<U30D7> <kn-hu>;<kn-KATA>;<kn-SEMIVOICED>;<IGNORE> % KATAkn  PU
%
<U3078> <kn-he>;<kn-HIRA>;<kn-NORMAL>;<IGNORE> % HIRAkn  HE
<U3079> <kn-he>;<kn-HIRA>;<kn-VOICED>;<IGNORE> % HIRAkn  BE
<U307A> <kn-he>;<kn-HIRA>;<kn-SEMIVOICED>;<IGNORE> % HIRAkn  PE
<U30D8> <kn-he>;<kn-KATA>;<kn-NORMAL>;<IGNORE> % KATAkn  HE
<UFF8D> <kn-he>;<kn-KATA>;<kn-NORMAL-HF>;<IGNORE> % hfwd KATAkn  HE
<U30D9> <kn-he>;<kn-KATA>;<kn-VOICED>;<IGNORE> % KATAkn  BE
<U30DA> <kn-he>;<kn-KATA>;<kn-SEMIVOICED>;<IGNORE> % KATAkn  PE
%
<U307B> <kn-ho>;<kn-HIRA>;<kn-NORMAL>;<IGNORE> % HIRAkn  HO
<U307C> <kn-ho>;<kn-HIRA>;<kn-VOICED>;<IGNORE> % HIRAkn  BO
<U307D> <kn-ho>;<kn-HIRA>;<kn-SEMIVOICED>;<IGNORE> % HIRAkn  PO
<U30DB> <kn-ho>;<kn-KATA>;<kn-NORMAL>;<IGNORE> % KATAkn  HO
<UFF8E> <kn-ho>;<kn-KATA>;<kn-NORMAL-HF>;<IGNORE> % hfwd KATAkn  HO
<U30DC> <kn-ho>;<kn-KATA>;<kn-VOICED>;<IGNORE> % KATAkn  BO
<U30DD> <kn-ho>;<kn-KATA>;<kn-SEMIVOICED>;<IGNORE> % KATAkn  PO
%
<U307E> <kn-ma>;<kn-HIRA>;<kn-NORMAL>;<IGNORE> % HIRAkn  MA
<U30DE> <kn-ma>;<kn-KATA>;<kn-NORMAL>;<IGNORE> % KATAkn  MA
<UFF8F> <kn-ma>;<kn-KATA>;<kn-NORMAL-HF>;<IGNORE> % hfwd KATAkn  MA
%
<U307F> <kn-mi>;<kn-HIRA>;<kn-NORMAL>;<IGNORE> % HIRAkn  MI
<U30DF> <kn-mi>;<kn-KATA>;<kn-NORMAL>;<IGNORE> % KATAkn  MI
<UFF90> <kn-mi>;<kn-KATA>;<kn-NORMAL-HF>;<IGNORE> % hfwd KATAkn  MI
%
<U3080> <kn-mu>;<kn-HIRA>;<kn-NORMAL>;<IGNORE> % HIRAkn  MU
<U30E0> <kn-mu>;<kn-KATA>;<kn-NORMAL>;<IGNORE> % KATAkn  MU
<UFF91> <kn-mu>;<kn-KATA>;<kn-NORMAL-HF>;<IGNORE> % hfwd KATAkn  MU
%
<U3081> <kn-me>;<kn-HIRA>;<kn-NORMAL>;<IGNORE> % HIRAkn  ME
<U30E1> <kn-me>;<kn-KATA>;<kn-NORMAL>;<IGNORE> % KATAkn  ME
<UFF92> <kn-me>;<kn-KATA>;<kn-NORMAL-HF>;<IGNORE> % hfwd KATAkn  ME
%
<U3082> <kn-mo>;<kn-HIRA>;<kn-NORMAL>;<IGNORE> % HIRAkn  MO
<U30E2> <kn-mo>;<kn-KATA>;<kn-NORMAL>;<IGNORE> % KATAkn  MO
<UFF93> <kn-mo>;<kn-KATA>;<kn-NORMAL-HF>;<IGNORE> % hfwd KATAkn  MO
%
<U3083> <kn-ya>;<kn-HIRA>;<kn-SMALL>;<IGNORE> % HIRAkn  SMALL YA
<U3084> <kn-ya>;<kn-HIRA>;<kn-NORAML>;<IGNORE> % HIRAkn  YA
<UFF6C> <kn-ya>;<kn-KATA>;<kn-SMAL-HFL>;<IGNORE> % hfwd KATAkn  SMALL YA
<U30E3> <kn-ya>;<kn-KATA>;<kn-SMALL>;<IGNORE> % KATAkn  SMALL YA
<U30E4> <kn-ya>;<kn-KATA>;<kn-NORMAL>;<IGNORE> % KATAkn  YA
<UFF94> <kn-ya>;<kn-KATA>;<kn-NORMAL-HF>;<IGNORE> % hfwd KATAkn  YA
%
<U3085> <kn-yu>;<kn-HIRA>;<kn-SMALL>;<IGNORE> % HIRAkn  SMALL YU
<U3086> <kn-yu>;<kn-HIRA>;<kn-NORAML>;<IGNORE> % HIRAkn  YU
<U30E5> <kn-yu>;<kn-KATA>;<kn-SMALL>;<IGNORE> % KATAkn  SMALL YU
<UFF6D> <kn-yu>;<kn-KATA>;<kn-SMAL-HFL>;<IGNORE> % hfwd KATAkn  SMALL YU
<U30E6> <kn-yu>;<kn-KATA>;<kn-NORMAL>;<IGNORE> % KATAkn  YU
<UFF95> <kn-yu>;<kn-KATA>;<kn-NORMAL-HF>;<IGNORE> % hfwd KATAkn  YU
%
<U3087> <kn-yo>;<kn-HIRA>;<kn-SMALL>;<IGNORE> % HIRAkn  SMALL YO
<U3088> <kn-yo>;<kn-HIRA>;<kn-NORAML>;<IGNORE> % HIRAkn  YO
<U30E7> <kn-yo>;<kn-KATA>;<kn-SMALL>;<IGNORE> % KATAkn  SMALL YO
<UFF6E> <kn-yo>;<kn-KATA>;<kn-SMAL-HFL>;<IGNORE> % hfwd KATAkn  SMALL YO
<U30E8> <kn-yo>;<kn-KATA>;<kn-NORMAL>;<IGNORE> % KATAkn  YO
<UFF96> <kn-yo>;<kn-KATA>;<kn-NORMAL-HF>;<IGNORE> % hfwd KATAkn  YO
%
<U3089> <kn-ra>;<kn-HIRA>;<kn-NORMAL>;<IGNORE> % HIRAkn  RA
<U30E9> <kn-ra>;<kn-KATA>;<kn-NORMAL>;<IGNORE> % KATAkn  RA
<UFF97> <kn-ra>;<kn-KATA>;<kn-NORMAL-HF>;<IGNORE> % hfwd KATAkn  RA
%
<U308A> <kn-ri>;<kn-HIRA>;<kn-NORMAL>;<IGNORE> % HIRAkn  RI
<U30EA> <kn-ri>;<kn-KATA>;<kn-NORMAL>;<IGNORE> % KATAkn  RI
<UFF98> <kn-ri>;<kn-KATA>;<kn-NORMAL-HF>;<IGNORE> % hfwd KATAkn  RI
%
<U308B> <kn-ru>;<kn-HIRA>;<kn-NORMAL>;<IGNORE> % HIRAkn  RU
<U30EB> <kn-ru>;<kn-KATA>;<kn-NORMAL>;<IGNORE> % KATAkn  RU
<UFF99> <kn-ru>;<kn-KATA>;<kn-NORMAL-HF>;<IGNORE> % hfwd KATAkn  RU
%
<U308C> <kn-re>;<kn-HIRA>;<kn-NORMAL>;<IGNORE> % HIRAkn  RE
<U30EC> <kn-re>;<kn-KATA>;<kn-NORMAL>;<IGNORE> % KATAkn  RE
<UFF9A> <kn-re>;<kn-KATA>;<kn-NORMAL-HF>;<IGNORE> % hfwd KATAkn  RE
%
<U308D> <kn-ro>;<kn-HIRA>;<kn-NORMAL>;<IGNORE> % HIRAkn  RO
<U30ED> <kn-ro>;<kn-KATA>;<kn-NORMAL>;<IGNORE> % KATAkn  RO
<UFF9B> <kn-ro>;<kn-KATA>;<kn-NORMAL-HF>;<IGNORE> % hfwd KATAkn  RO
%
<U308E> <kn-wa>;<kn-HIRA>;<kn-SMALL>;<IGNORE> % HIRAkn  SMALL WA
<U308F> <kn-wa>;<kn-HIRA>;<kn-NORAML>;<IGNORE> % HIRAkn  WA
<U30EE> <kn-wa>;<kn-KATA>;<kn-SMALL>;<IGNORE> % KATAkn  SMALL WA
<U30EF> <kn-wa>;<kn-KATA>;<kn-NORMAL>;<IGNORE> % KATAkn  WA
<UFF9C> <kn-wa>;<kn-KATA>;<kn-NORMAL-HF>;<IGNORE> % hfwd KATAkn  WA
<U30F7> <kn-wa>;<kn-KATA>;<kn-VOICED>;<IGNORE> % KATAkn  VA
%
<U3090> <kn-wi>;<kn-HIRA>;<kn-NORAML>;<IGNORE> % HIRAkn  WI
<U30F0> <kn-wi>;<kn-KATA>;<kn-NORMAL>;<IGNORE> % KATAkn  WI
<U30F8> <kn-wi>;<kn-KATA>;<kn-VOICED>;<IGNORE> % KATAkn  VI
%
<U3091> <kn-we>;<kn-HIRA>;<kn-NORAML>;<IGNORE> % HIRAkn  WE
<U30F1> <kn-we>;<kn-KATA>;<kn-NORMAL>;<IGNORE> % KATAkn  WE
<U30F9> <kn-we>;<kn-KATA>;<kn-VOICED>;<IGNORE> % KATAkn  VE
%
<U3092> <kn-wo>;<kn-HIRA>;<kn-NORAML>;<IGNORE> % HIRAkn  WO
<U30F2> <kn-wo>;<kn-KATA>;<kn-NORMAL>;<IGNORE> % KATAkn  WO
<UFF66> <kn-wo>;<kn-KATA>;<kn-NORMAL-HF>;<IGNORE> % hfwd KATAkn  WO
<U30FA> <kn-wo>;<kn-KATA>;<kn-VOICED>;<IGNORE> % KATAkn  VO
%
<U3093> <kn-n>;<kn-HIRA>;<kn-NORAML>;<IGNORE> % HIRAkn  N
<U30F3> <kn-n>;<kn-KATA>;<kn-NORMAL>;<IGNORE> % KATAkn  N
<UFF9D> <kn-n>;<kn-KATA>;<kn-NORMAL-HF>;<IGNORE> % hfwd KATAkn  N
        ---
<U3099> <kn-cmb-voice>;<kn-HIRA>;<kn-NORAML>;<IGNORE> % comb voice
<U309A> <kn-cmb-semivoice>;<kn-HIRA>;<kn-NORAML>;<IGNORE> % comb semi-voice
<U309B> <kn-voice>;<kn-HIRA>;<kn-NORAML>;<IGNORE> % voice
<UFF9E> <kn-voice>;<kn-HIRA>;<kn-NORAML-HF>;<IGNORE> % hhwd voice
<U309C> <kn-semivoice>;<kn-HIRA>;<kn-NORAML>;<IGNORE> % semi-voice
<UFF9F> <kn-semivoice>;<kn-HIRA>;<kn-NORAML-HF>;<IGNORE> % hfwd semi-voice
<U309D> <kn-iter>;<kn-HIRA>;<kn-NORMAL>;<IGNORE> % HIRAGANA iter MARK
<U30FD> <kn-iter>;<kn-HIRA>;<kn-VOICED>;<IGNORE> % HIRAGANA VOICED iter MARK
<U309E> <kn-iter>;<kn-KATA>;<kn-NORMAL>;<IGNORE> % KATAKANA iter MARK
<U30FE> <kn-iter>;<kn-KATA>;<kn-VOICED>;<IGNORE> % KATAKANA VOICED iter MARK
%
<U30FB> <IGNORE>;<IGNORE>;<IGNORE>;<U30FB> % KATAKANA MIDDLE DOT
<UFF65> <IGNORE>;<IGNORE>;<IGNORE>;<UFF65> % hfwd KATAKANA MIDDLE DOT
<U30FC> <IGNORE>;<IGNORE>;<IGNORE>;<U30FC> % prolong
<UFF70> <IGNORE>;<IGNORE>;<IGNORE>;<UFF70> % hfwd prolong
<UFF61> % hfwd HALFWIDTH IDEOGRAPHIC FULL STOP -- to be handled with <U3002>
<UFF62> % hfwd HALFWIDTH LEFT CORNER BRACKET -- to be handled with <U300C>
<UFF63> % hfwd RIGHT CORNER BRACKET -- to be handled with <U300D>
<UFF64> % HALFWIDTH IDEOGRAPHIC COMMA -- to be handled with <U3001>

________________________end of Japan comments ___________________________
__________beginning of Netherlands comments accompanying negative _____

From: John Bijlsma <John.Bijlsma@nni.nl>


JTC1 SC22 N2364, ISO/IEC CD 14651
IT - International String Ordering - Method for
Comparing Character Strings and Description of a
Default Tailorable Ordering
97-04-24, DISAPPROVAL WITH COMMENT
......................................................

The Netherlands vote negative on CD 14651. To turn our vote to positive
modifications shall be made in accordance with our comments. We reserve
our final position regarding the CD until we have seen the Final CD.

Technical comments:

1.  Remove Annex 1 and all references to an International Default Order.

-- SC22 has no expertise in this field, and cannot check for correctness
    Most NBs in SC22 are not able to check whether a proposed ordering
    for a certain unfamiliar script is in agreement to actual practice
    far from home. Those NBs that are familiar are not represented in
    SC22, nor have been asked for comment.

-- Default order is an instrument of cultural imperialism.
    In several countries more than one ordering rule is in use without
    any agreed preference. Calling one of these the "default" is
    imposing an extraneous pressure, and will involve interference with
    national habits.

-- No need for a default.
    No country uses always all characters from 10646. They should not be
    burdened with unwanted features. A method for supplying ordering
    information for a given restricted character set to an API should be
    contained in 14651 itself, without reference to 14652.

2.  Remove all references to 14652.

-- Needless complexity should be avoided.
    An ISO standard should  be as independent as possible of other ISO
    standards. If ordering information can only be supplied by way
    of a complete set of cultural conventions, as specified in 14652,
    there is involved an enormous overhead, and an obligation to NBs of
    also having to specify non-ordering information which is irrelevant
    to 14651, but nevertheless required in this CD.

Editorial comments:

The text of this document leaves much to be desired regarding
precision of definition, clarity of presentation and conformance to
ISO directives part-3.
The NNI cannot give detailed comments here, nor offer replacement text as
doing so would require rewriting more than half of the document for which  
we have no resources available. The NNI already gave some directions with
its vote on CD-registration, but found almost no improvement in this CD.

__________________________end of Netherland comments ________________
_________beginning of USA comments accompanying negative _____________


The US National Body votes to Disapprove ISO/IEC CD 14651 with the following
comments:

These are the U.S. comments for the first CD ballot for ISO/IEC CD 14651,
International String Ordering (SC22 N2364).

No alternative text is supplied as part of this response because a lot of it
would have to be written.  Here are the concerns:


AF-1

The specification of the sorting algorithm must be made independently of a
programming model.

Sorting is a process that is used in an incredible variety of circumstances
and on widely different systems, including object-oriented systems.  Care
should be taken in preparing the normative specifications for CD 14651 that
they are usable independent of a particular programming model, programming
language, or environment.

In particular, the descriptions of the sorting operations should be 
expressed
in an abstract form, specifying IN, OUT and RETURN parameters but "without"
language binding. Also, no parameters needed for the sorting operation may 
be
presumed to hide in some semi-opaque state, but rather they should always be
specified explicitly in the description of the operation.

If it is desired to show how the standard might be implemented in a POSIX
environment, that could be the subject of an informative annex. Function
bindings for POSIX could assume transparent access to locale data from the
POSIX locale model, if that is desired. The annex would specify how the
proposed POSIX functions make use of the abstract operations defined in the
normative part of the standard, and how their parameters are set either
explicitly or implicitly.


RLG 1:

The body of the standard includes material which belongs in an informative
annex, specifically the "Tutorial on problems solved by this standard."

RLG 2:

The order specified for two Cyrillic characters (p. 95-100 of the CD)
conflicts with the order in Table 2 of ISO/R9 and other sources (cited 
below).
 The characters in question are these two case pairs:  CYRILLIC CAPITAL 
LETTER
TSHE/CYRILLIC SMALL LETTER TSHE and CYRILLIC CAPITAL LETTER DZE/CYRILLIC 
SMALL
LETTER DZE.

Cyrillic letter TSHE:
In the CD, TSHE follows KA WITH HOOK and precedes EL.
In ISO/R9 and other sources, TSHE follows TE and precedes U.

Cyrillic letter DZE:
In the CD, DZE follows KOPPA and precedes CHE.
In ISO/R9 and other sources, DZE follows ZE and precedes I.

Other differences in the order of Cyrillic characters between the CD and 
Table
2 of ISO/R9 are either not supported by the other sources or are arbitrary.

RLG 3:

The order of scripts on p. 31 differs slightly from the order in ISO/IEC
10646.  Specifically:
 - Georgian follows Cyrillic; in ISO/IEC 10646, it follows Tibetan (pDAM-6)
 - Hebrew follows Arabic, in ISO/IEC 10646, it follows Armenian (and  
precedes Arabic).
These differences are not explained.

RLG 4:

Hangul is positioned between Tibetan and Cherokee (i.e., consistent with the
location of Hangul Jamo in ISO/IEC 10646).  There is no explanation as to 
why this position was chosen, rather than that of Hangul Syllables.  Since 
Korean may be written with a mixture of ideographs and Hangul syllables,
the Hangul Syllables position established by pDAM-5, immediately after the
CJK Unified Ideographs, might be preferable.


HP 1

The outline of the document does not follow the well defined and established
method already used in other JTC1 standards.  For example, the Introduction 
is too big and the reader gets lost and might decide not to continue to
read the document. Usually such information belongs to an informative
annex otherwise it becomes normative.

HP 2

The structure of the document has the "Scope" clause on page 11.  This 
clause should come immediately after a newly written short Introduction
clause.  In addition, this clause needs clarifications.  For example, does
it describes the APIs needed by applications to specify character string
ordering?  It is also not clear what is meant by the phrase "full
repertoire of ISO/IEC 10646 (independently of coding)".  The part that is
not clear in the previous statement is the one in parenthesis.  In
addition, the "Scope" clause talks about a specific default ordering but
it is not clear as to where in the CD how it was derived or how it is
related to the APIs.

HP 3

The "Conformance" clause should follow immediately the "Scope" clause.  It
should be combined with the "Requirements" clause.  It should be rewritten 
to make easy to understand how to conform without having to go through the 
syntax and content complexity of the "Requirements" clause.

Conformance is difficult to determine from the document; the document 
requires a table of precisely which features are required. Moreover, the
functions levels are, in general, independent of the previous level; there
is little reason to force all features of one level before the next higher
is reached.  Post handling is informative, and has no place in
conformance.

HP 4

In the clause "Tailoring Mechanism", it is not clear at all as to what an
application developers needs to do to override the default ordering that is
specified in Annex 1.

HP 5

May be it would be better to have this CD become a Technical Report rather
than a standard since it allows users to override the default ordering
proposed and there might be more users overriding the default, with an
undefined and nowhere described mechanism, than what the CD proposes.

HP 6

Dependency on an unpublished standard 14652, Cultural Conventions
Specification is too high.  Currently, 14652 is still in the CD stage as
mentioned in clause 2, Normative References, of this CD (14651).

In summary, there is a lot of structural and technical fine tuning that is
necessary to make this document complete.  If such an effort takes too much
time may be the industry could be served better if the proposal is modified
for publication as a TR rather an ISO standard.  This work can be later
converted to an ISO publication when CD 14652, Cultural Conventions
Specification, is accepted and is published as an ISO standard.


TG 1

The organization and nomenclature (e.g. COMPCAR) in unnecessarily obscure.
Names should be spelled out completely for clarity.

TG 2

The requirement that the original string be recoverable is unnecessary; many
applications, such as databases, will have a sort key be an alternate field 
in the record. They may only need to have a level 1 sort for their
application.  In that case, storing the original string twice or requiring
internal structure that enables reconstruction is unnecessary and only
increases storage to no purpose.

TG 3

Use of NBSP is in practice an unacceptable overload of its primary function.
Being able to functionally tailor just space and nbsp is in practice not
useful; in general a whole host of similar characters, punctuation and
symbols, behave the same way.

TG 4

The algorithm for comparison must be stated in terms of results, NOT a
specific mechanism.

TG 5

The format in Annex 1 is unnecessarily complex. It is impossible to assess 
and recommend this standard where we cannot clearly determine the result
of the default sorting order rules in this annex.  It forces use of a
whole separate notation for characters. To correct this, characters must
always be referred to by their full 10646 name for clarity, rather than
arbitrary notations such as AYEHS, AIGUT, POINN, QARNP, or many other
examples. Script names should always be the 10646 block name.

TG 6

The equivalencies of composed characters vs. composite character sequences;
e.g. a + umlaut and a-umlaut can be stated much more succinctly.

TG 7

The relative ordering of characters cannot be determined from the character
lists, since they are not even remotely in the resulting order.  To correct
this, the ordering of characters within a script must be presented in the
resulting order as much as possible. Example:

<U0000> IGNORE;IGNORE;IGNORE;<U0000> % NULL
<U2400> IGNORE;IGNORE;IGNORE;<U2400> % SYMBOL FOR NULL
<U0001> IGNORE;IGNORE;IGNORE;<U0001> % START OF HEADING
<U2401> IGNORE;IGNORE;IGNORE;<U2401> % SYMBOL FOR START OF HEADING
<U0002> IGNORE;IGNORE;IGNORE;<U0002> % START OF TEXT
<U2402> IGNORE;IGNORE;IGNORE;<U2402> % SYMBOL FOR START OF TEXT
<U0003> IGNORE;IGNORE;IGNORE;<U0003> % END OF TEXT
<U2403> IGNORE;IGNORE;IGNORE;<U2403> % SYMBOL FOR END OF TEXT
...
The fourth column (in this case) determines the final ordering of the
characters, which is NOT the order presented. It must be presented as:

<U0000> IGNORE;IGNORE;IGNORE;<U0000> % NULL
<U0001> IGNORE;IGNORE;IGNORE;<U0001> % START OF HEADING
<U0002> IGNORE;IGNORE;IGNORE;<U0002> % START OF TEXT
<U0003> IGNORE;IGNORE;IGNORE;<U0003> % END OF TEXT
...
<U2400> IGNORE;IGNORE;IGNORE;<U2400> % SYMBOL FOR NULL
<U2401> IGNORE;IGNORE;IGNORE;<U2401> % SYMBOL FOR START OF HEADING
<U2402> IGNORE;IGNORE;IGNORE;<U2402> % SYMBOL FOR START OF TEXT
<U2403> IGNORE;IGNORE;IGNORE;<U2403> % SYMBOL FOR END OF TEXT

TG 8

The Annex also does not make clear that the vast majority of its characters
are sorted in character code order. This requires the reader to visually
inspect every line to no purpose. These should be replaced one statement;
"Except where otherwise noted, all symbols are sorted as:

<Uxxxx> IGNORE;IGNORE;IGNORE;<Uxxxx>"

TG 9

Annex 2
List #1 is superfluous. The statement should be that the words in List#2 in
any initial order, when sorted will result in List #2.

______________________ end of USA comments __________________________
_________beginning of Israel comments accompany negative ________________

THE STANDARDS INSTITUTE OF ISRAEL (SII)

Comments on ISO/IEC CD 14651 (ISO/IEC JTC 1/SC22/WG20 N471en)

The SII votes NO on CD 14651.  If items 1, 2 and 3 were to be accepted,
our vote would become YES.

1.  Hebrew Accents

The Hebrew accents (UO591 to UO5AF), Meteg (UO5BD) and Upper Dot (UO5C4)
do not participate in the string ordering process.  They relate, in fact,
to the whole word, rather than to the letter to which they are attached,
and are never used in the lexicographic order or in any other ordering of
Hebrew texts.

-  The Hebrew accents should be removed from the list of collating
symbols, page 35, and from page 45.

-  On page 56 they should all be defined as:

         -  IGNORE; IGNORE; IGNORE; IGNORE;


2.  Composite characters and combining characters.

It seems that combining characters do not sort and compare as equivalent
to their precomposed encoding.  For instance, the two strings "Gu:nther"
and "Gu:nther", the first coded with UOOFC, the second with UOO75 followed
by UO3O8, are equivalent and should not be distinguished but are not
equivalent in the CD.  The particular coding used is an artifact, possibly
not under the control of the user, and is normally meaningless.

3.  Introduction, page 6, last paragraph:  "If two equivalent strings are
not absolutely identical, then the tie must be broken."

This sentence is not acceptable.  If two strings are equivalent they
should be treated as such.  For example, Hebrew strings that are
equivalent but have different accents.

4.  Introduction, page 4 (Editorial):

The introduction begins with a negative statement and continues with a
criticism of past practices.  The SII suggests it should be preferable to
begin with a positive statement describing what the standard is and what
are its benefits.

5.  Tutorial, page 7 (Editorial).

The tutorial would be better placed in an informative appendix.

6.  Page 35 (Editorial).

The comment should be qubuts (the s is mussing).

________________end of Israel comments; end of document SC22 N2466 ____