Subject: SC22 N2719 - Voting Summary for FCD 14651 - Method for Comparing Character Strings and Description of the Common Template Tailorable Ordering

From: "william c. rinehuls" <[email-masked]>
Date: Mon, 18 May 1998 14:19:08 -0400 (EDT)

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

TITLE:
Summary of Voting on FCD Approval of FCD 14651 - Information technology -
International String Ordering and Comparison - Method for Comparing
Character Strings and Description of the Common Template Tailorable
Ordering

DATE ASSIGNED:
1998-05-18

SOURCE:
Secretariat, ISO/IEC JTC 1/SC22

BACKWARD POINTER:
N/A

DOCUMENT TYPE:
Summary of Voting

PROJECT NUMBER:
JTC 1.22.30.02.02

STATUS:
WG20 is requested to prepare a Disposition of Comments Report and a
recommendation on the further processing of the FCD.

ACTION IDENTIFIER:
FYI to SC22 Member Bodies
ACT to WG20

DUE DATE:
N/A

DISTRIBUTION:
Text

CROSS REFERENCE:
SC22 N2607

DISTRIBUTION FORM:
Def

Address reply to:
ISO/IEC JTC 1/SC22 Secretariat
William C. Rinehuls
8457 Rushing Creek Court
Springfield, VA 22153 USA
Telephone:  +1 (703) 912-9680
Fax:  +1 (703) 912-2973
email:  [email-masked]

______________ end of title page; beginning of overall summary ________

                          SUMMARY OF VOTING ON

Letter Ballot Reference No:  SC22 N2607
Circulated by:               JTC 1/SC22
Circulation Date:            1997-12-12
Closing Date:                1998-04-30
Closing Date Extended to:    1998-05-15 (at the reqwest of Australia)

SUBJECT:
FCD Approval for FCD 14651 - Information technology - International String
Ordering and Comparison - Method for Comparing Character Strings and
Description of the Common Template Tailorable Ordering

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

"P" Members supporting approval
       without comments                         10

"P" Members supporting approval
       with comments                             2

"P" Members not supporting approval              5

"P" Members abstaining                           3

"P" Members not voting                           2

"O" Members supporting approval
       without comments                          1

"P" Members not supporting approval              1

---------------------------------------------------------------------
Secretariat Action:

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

The comments accompanying the affirmative votes from Canada and Ireland,
and the negative votes from Denmark, Japan, Netherlands, Sweden, United
Kingdom and the USA are attached.

The comment accompanying the abstention vote from Australia was:  "Not
enough time to consider this proposal due to the late arrival of the
document."  The comment accompanying the abstention vote from Austria was:
"Lack of expert resources."  The comment accompanying the abstention vote
from Germany was "There is no national rapporteur." 

Secretariat comment:  The document has been available to all SC22 Member
Bodies either electronically or in paper form since December 1997.

___________ end of overall summary; beginning of detail summary _______

                 ISO/IEC JTC1/SC22  LETTER BALLOT SUMMARY

PROJECT NO:    JTC 1.22.30.02.02

SUBJECT:  
FCD Approval for FCD 14651 - Information technology - International String
Ordering and Comparison - Method for Comparing Character Strings and
Description of the Common Template Tailorable Ordering
          
Reference Document No:   N2607           Ballot Document No:  N2607
Circulation Date:        12-12-1997                    
Closing Date:            1998-04-30 
Closing Date Extended to 1998-05-15 (at the request of Australia)                  
 
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)       (X)       ( )
Austria                 ( )      ( )       (X)       (X)       ( )
Belgium                 (X)      ( )       ( )       ( )       ( )
Brazil                  (X)      ( )       ( )       ( )       ( )    
Canada                  (X)      ( )       ( )       (X)       ( )
China                   (X)      ( )       ( )       ( )       ( )
Czech Republic          (X)      ( )       ( )       ( )       ( )
Denmark                 ( )      (X)       ( )       (X)       ( )
Egypt                   ( )      ( )       ( )       ( )       (X)
Finland                 (X)      ( )       ( )       ( )       ( )
France                  (X)      ( )       ( )       ( )       ( )
Germany                 ( )      ( )       (X)       (X)       ( )
Ireland                 (X)      ( )       ( )       (X)       ( )
Japan                   ( )      (X)       ( )       (X)       ( )
Netherlands             ( )      (X)       ( )       (X)       ( )
Norway                  (X)      ( )       ( )       ( )       ( )
Romania                 (X)      ( )       ( )       ( )       ( )
Russian Federation      (X)      ( )       ( )       ( )       ( )
Slovenia                ( )      ( )       ( )       ( )       (X)
UK                      ( )      (X)       ( )       (X)       ( )
Ukraine                 (X)      ( )       ( )       ( )       ( )
USA                     ( )      (X)       ( )       (X)       ( )

'O' Members Voting

Korea Republic          (X)      ( )       ( )       ( )       ( )
Sweden                  ( )      (X)       ( )       (X)       ( )

___________ end of detail summary; beginnin of Canada comments _______

Document Number  FCD14651   (22N2607)

Canada APPROVES WITH THE FOLLOWING COMMENTS:

Canada votes YES on FCD ballot on 14651, with the following comments:

1. On the condition that normalizing characters to either precomposed 
   sequences or decomposed sequences for characters which have double 
   coding (called canonical equivalences according to the Unicode 
   standard) is made mandatory, Canada is of opinion that combining
   marks should have a second level equivalent to the precomposed forms'
   second level (ex. precomposed character é [E ACUTE] has a weight for
   the acute accent at the second level. The character COMBINING ACUTE
   should have the same second level weight). This comment is to solve the
   problem raised by the Unicode consortium about canonical equivalences.
   However we insist that this scheme technically works only if 
   normalization of character sequences is mandated, a direction to which
   the Unicode consortium now agreed and added/specified in consequence 
   in its own algorithm.

2. The syntactic mistakes of the table should be fixed and passed through
   an existing commercial locale parser such as the one of AIX for final
   checking.

3. Reestablish the COLL_WEIGHT_MAX=4 after the LC_COLLATE statement. We 
   believe that this parameter should be clarified in 14652 as being a 
   declaration of the maximum number of levels used in the table. This is 
   very useful for not having to parse the table twice, just to determine 
   storage allocation before processing the table. A comment to that 
   effect will also be done for the ballot on 14652.

4. The annex I of the previous CD should be reintroduced, however with 
   nonrelevant parameters removed from the example as per our previous 
   Canadian comment.

________ end of Canada comments; beginning of Denmark comments _______

Vote from Danish Standards Association on FCD 14651 - Sorting - SC22 N2607.

The Danish member body vote is "no" with comments.

If the technical comments can be solved satisfactorily, the Danish "no"
vote can be changed to "yes", unless other significant changes be made to
the standard in an unsatisfactory way.

An example of an unsatisfactory change to the standard is the technical
annex in SC22 N2608 on an example user interface, which is out of scope of
the standard, and does not explain the relation to the APIs and
specifications in the standard, which is not trivial. The user interface
assumes that a number of tailored sorting specifications be available at
runtime, presumably in compiled binary form, and that selecting mechanisms
be available.

Technical comments.

1. On page 120, an "order_end" and an "END LC_COLLATE" statement is
missing.

2. A number of scripts should have a specified ordering.

3. It needs to be explained that it is not necessary to convert into
binary sorting strings to do the comparison. The comparison can be done
character by character on the fly, and this may often resultin a
difference within the first few characters, thus avoiding costly complete
conversion of both the strings for comparison. This should at least be
explained for COMPCAR.

4. It needs to be explained that the binary strings are locale dependent
and therefore not adequate for storing, in databases and the like. A note
on this should be available for CHARABIN.

5. As a number of national specifications have been developed using
specific naming of weights different from the names in the standard it is
necessary to support this existing practise to add these weights via the
"symbol-equivalence" statement of 14652. The weights in question include:

collating-symbol <NONE>
collating-symbol <ACUTE>
collating-symbol <ACUTE+DOT>
collating-symbol <GRAVE>
collating-symbol <DOUBLE-GRAVE>
collating-symbol <BREVE>
collating-symbol <BREVE+ACUTE>
collating-symbol <BREVE+GRAVE>
collating-symbol <BREVE+MACRON>
collating-symbol <BREVE+HOOK>
collating-symbol <BREVE+TILDE>
collating-symbol <BREVE+DOT-BELOW>
collating-symbol <BREVE-BELOW>
collating-symbol <INVERTED-BREVE>
collating-symbol <CIRCUMFLEX>
collating-symbol <CIRCUMFLEX+ACUTE>
collating-symbol <CIRCUMFLEX+GRAVE>
collating-symbol <CIRCUMFLEX+HOOK>
collating-symbol <CIRCUMFLEX+TILDE>
collating-symbol <CIRCUMFLEX+DOT-BELOW>
collating-symbol <CARON>
collating-symbol <CARON+DIAERESIS>
collating-symbol <CARON+DOT>
collating-symbol <RING>
collating-symbol <RING+ACUTE>
collating-symbol <RING-BELOW>
collating-symbol <DIAERESIS>
collating-symbol <DIAERESIS+MACRON>
collating-symbol <DIAERESIS+ACUTE>
collating-symbol <DIAERESIS+GRAVE>
collating-symbol <DIAERESIS+CARON>
collating-symbol <DOUBLE-ACUTE>
collating-symbol <HOOK>
collating-symbol <TILDE>
collating-symbol <TILDE+ACUTE>
collating-symbol <TILDE+DIAERESIS>
collating-symbol <TILDE-BELOW>
collating-symbol <DOT>
collating-symbol <DOT-BELOW>
collating-symbol <DOT+DOT-BELOW>
collating-symbol <STROKE>
collating-symbol <STROKE+ACUTE>
collating-symbol <CEDILLA>
collating-symbol <CEDILLA+ACUTE>
collating-symbol <CEDILLA+GRAVE>
collating-symbol <CEDILLA+BREVE>
collating-symbol <OGONEK>
collating-symbol <OGONEK+MACRON>
collating-symbol <MACRON>
collating-symbol <MACRON+ACUTE>
collating-symbol <MACRON+GRAVE>
collating-symbol <MACRON+DIAERESIS>
collating-symbol <MACRON+DIAERESIS-BELOW>
collating-symbol <MACRON+DOT>
collating-symbol <MACRON+DOT-BELOW>
collating-symbol <MACRON+CIRCUMFLEX>
collating-symbol <LINE-BELOW>
collating-symbol <HORN>
collating-symbol <HORN+ACUTE>
collating-symbol <HORN+GRAVE>
collating-symbol <HORN+HOOK>
collating-symbol <HORN+TILDE>
collating-symbol <HORN+DOT-BELOW>
collating-symbol <PRECEDED-BY-APOSTROPHE>
collating-symbol <GREEK>
collating-symbol <PSILI>
collating-symbol <PSILI+VARIA>
collating-symbol <PSILI+VARIA+PROSGEGRAMENI>
collating-symbol <PSILI+VARIA+YPOGEGRAMMENI>
collating-symbol <PSILI+OXIA>
collating-symbol <PSILI+OXIA+PROSGEGRAMENI>
collating-symbol <PSILI+OXIA+YPOGEGRAMMENI>
collating-symbol <PSILI+PERISPOMENI>
collating-symbol <PSILI+PERISPOMENI+PROSGEGRAMENI>
collating-symbol <PSILI+PERISPOMENI+YPOGEGRAMMENI>
collating-symbol <PSILI+PROSGEGRAMENI>
collating-symbol <PSILI+YPOGEGRAMMENI>
collating-symbol <DASIA>
collating-symbol <DASIA+VARIA>
collating-symbol <DASIA+VARIA+PROSGEGRAMENI>
collating-symbol <DASIA+VARIA+YPOGEGRAMMENI>
collating-symbol <DASIA+OXIA>
collating-symbol <DASIA+OXIA+PROSGEGRAMENI>
collating-symbol <DASIA+OXIA+YPOGEGRAMMENI>
collating-symbol <DASIA+PERISPOMENI>
collating-symbol <DASIA+PERISPOMENI+PROSGEGRAMENI>
collating-symbol <DASIA+PERISPOMENI+YPOGEGRAMMENI>
collating-symbol <DASIA+PROSGEGRAMENI>
collating-symbol <DASIA+YPOGEGRAMMENI>
collating-symbol <VRACHY>
collating-symbol <GREEK-MACRON>
collating-symbol <VARIA>
collating-symbol <VARIA+PROSGEGRAMENI>
collating-symbol <VARIA+YPOGEGRAMMENI>
collating-symbol <OXIA>
collating-symbol <OXIA+PROSGEGRAMENI>
collating-symbol <OXIA+YPOGEGRAMMENI>
collating-symbol <PERISPOMENI>
collating-symbol <PERISPOMENI+PROSGEGRAMENI>
collating-symbol <PERISPOMENI+YPOGEGRAMMENI>
collating-symbol <TONOS>
collating-symbol <PROSGEGRAMENI>
collating-symbol <YPOGEGRAMMENI>
collating-symbol <DIALYTICA>
collating-symbol <DIALYTICA>
collating-symbol <DIALYTICA+VARIA>
collating-symbol <DIALYTICA+OXIA>
collating-symbol <DIALYTICA+PERISPOMENI>
collating-symbol <DIALYTICA+TONOS>
collating-symbol <CYRILLIC>
collating-symbol <HIRAGANA>
collating-symbol <KATAKANA>
collating-symbol <SPECIAL>
collating-symbol <LAST>
collating-symbol <CAPITAL>
collating-symbol <CAPITAL-SMALL>
collating-symbol <SMALL-CAPITAL>
collating-symbol <SMALL>
collating-symbol <SUPERSCRIPT>
collating-symbol <SUBSCRIPT>
collating-symbol <OTHER>

6. It is wrong to define weights two times. Weights <a8> etc. on page
44-51 needs to be deleted.

Editorial comments:

1. The standard should use established weight names such as the ones in
ISO/IEC 9945-2 annex G and many POSIX locales, and not reinvent the wheel.

2. The annexes should use normal ISO numbering, and normative annexes
should be using numbers "A" and "B" etc.

3. a reference should be made to ISO/IEC 9899 programming language C,
possibly in the normative references.

This concludes the DS ballot text on SC22 N2607.

----------- end of Denmark comments; beginning of Ireland comments ____

VOTE ON COMMITTEE DRAFT:  FCD 14651
Date of Circulation:  12-12-1997        Reference Number:
Closing Date for Voting:  04-30-1998    ISO/IEC JTC 1/SC22 N2607
-------------------------------------------------------------------------
P-members have an obligation to vote
-------------------------------------------------------------------------
CD       FCD 14651

TITLE:   Information technology - International String Ordering and
         Comparison - Method for Comparing Character Strings and
         Description of the Common Template Tailorable Ordering
--------------------------------------------------------------------------
Please put an "X" on the appropriate line(s)

Approval of the draft:

_____  as presented

_____  with comments attached

******  Ireland approves with the following comments

       _____  general

******  Ireland believes that this standards is important and timely.
However, we see a need for harmonization with work done in this area by
the Unicode Consortium where possible and practicable, in order to
increase the likelihood that standard will actually be used.

       _____  technical

******  Normalization of characters to either recomposed sequences or
decomposed sequences should be made mandatory.

******  Errors in the specification table (for instance, in Cyrillic and
elsewhere) should be corrected.
******  A version of informative Annex I of the previous CD should be put
back into the standard.

       _____  editorial

******  The entire English text needs to be revised for language.

_____  Disapproval of the draft for reasons attached

       _____  Acceptance of these reasons and appropriate changes in the
              text will change our vote to approval

_____  Abstention (for reasons below)

National Standards Authority of Ireland
P-member voting
Date:   30 April 1998         Signature (if mailed)  Dr. I.J. Cowan

______________ end of Ireland comments; beginning of Japan comments ____

From [email-masked] Thu Apr  2 12:39:23 1998

Subject: Japan's vote on FCD 14651 (N2607)

SC 22 N 2607: FCD 14651
Method for Comparing Character Strings and the Description of
Common Template Tailorable Ordering.

(X) Disapproved

             National Body: Japan
             Date: 1998-02-17
             Signature: KATSUHIKO KAKEHI

--------------------------------------------------------------
The National Body of Japan disapproves FCD 14651 for the
reasons below. 

If the comments are satisfactorily resolved, Japan will
change its vote to approval. 

J.1) Considering the high dependency of this FCD on ISO/IEC 14652, 
Japan requests to wait and synchronize the review of FCD 14651 until 
FCD 14652 is approved.

J.2) The concept of the common template is not consistent in this draft 
as follows:

a) on one hand, the draft defines that the common template is not 
a default ordering, in the following text:

   a.1) the text in 7.1 Data specification -- 

	Although the data in table 1 defines a specific ordering, 
	it should not be considered as an internationally acceptable 
	default ordering but only as a starting point for the 
	tailoring process prescribed in the next paragraph.

   a.2) the content of the common template in Annex 1 is designed so as to 
      invoke an intentional mistake if it is parsed without tailoring --
      defining some toggle switches.

b) on the other hand, the draft describes as if the common template were
a default ordering, in the following places:

   b.1) the text at the beginning of Clause 5 Requirements --

	Hence the first conformance level (conformance level A) is 
	limited to a comparison API using the fixed common template 
	specified in annex 1 (table 1) with the result precision fixed; 

   b.2) the descriptions of the parameter "table" in the procedures
        COMPCAR and CARABIN -- 

	    - table: the name of the ordering table to be used to 
	make the comparison. This is only required for conformance
	level C. If this parameter is not provided, the common template 
	will be assumed. ...

Japan's proposals for the problem:

c.1) keep the a.1 and a.2 as it is (except for some detail),  

c.2) change b.1 as to delete the first conformance level

c.3) change b.2 as to invoke the implementation dependent table
	if the parameter "table" is not provided.

J.3) The relation to ISO/IEC 14652 is not well described. 

The last sentence in the first bullet of the Clause 1 Scope should be 
changed from 

	This interface uses transformation tables derived from either the 
	common template provided or from its tailoring.

to the two sentences

	This interface uses transformation tables which conforms to
	the specifications for LC_COLLATE in ISO/IEC 14652.
	The table shall be derived from either the common template
        provided or from its tailoring as defined in this standard.

J.4) The term "prehandling" should be applied to a process handling 
character strings to be compared as defined in Clause 3.

Japan's proposal:

1) Change the title of Subclause 5.1 from "prehandling phase" to
"preprocessing phase" or "preparation phase"

2) Change the title of Subclause 5.1.1 from "prehandling of the symbolic 
table data" to "preparation of the symbolic table data".

3) Change the first sentence of the fourth paragraph of 5.1.1 from

	As prehandling can be done on many different tables in a given 
	application environment, each one shall be identified by a name in
	this environment

to 

	As preparation may be done to generate more than one table in a
        given application environment, each one shall be identified by a
        name in this environment

J.5) In splitting the functionality of COMPCAR into COMPBIN and CARABIN,
the concept of "precision" is introduced in COMBIN in this draft.

But adding the parameter "precision" also in CARABIN will produce a 
comparable bit string shorter than the one for full precision and
those shorter strings are preferable in many situations.

J.6) The definition 

	collating symbol   a symbol used to specify weights assigned 
	to a character in a symbolic fashion rather than absolutely

is not understandable.  What word does the word "absolutely" correspond?

J.7) The definitions for "first order token", "second order token", 
"third order token", and "fourth order token" should be merged to

	n-th order token: an absolute number used as a comparison element
	corresponding to the n-th column of a line in the table.

	In the typical case of Latin characters, there are 
	four levels of tokens and the first three levels of token 
	describes a character (note that some 
	characters, such as ligatures, may lead to more than one token 
	for a character at one given level) while the fourth order token 
	describes a special character, or specifying the position of the 
	special character represented in the original string; 
	tokens of the fourth order level are always in pairs, the first 
	token being a position, 
	the second one being a weight for the character represented.

J.8) The symbols and abbreviations introduced in Clause 4 seems to appear
only in Annex 1 and the second, fourth and fifth paragraphs are not 
appropriate for "Symbols and abbreviations". It is recommended to put 
the material into subclause 5.4 or Annex 1.

J.9) The sentence in Clause 4

	If a character outside of the standard repertoire of ISO/IEC 10646 
	is to be used in tailored ordering tables, it is recommended that 
	the code-independent symbol identifying this character use the form 
	<U8XXXXXXX> for documentary purposes indicating its nonstandard 
	nature

is not understandable for many readers and apt to be upset by future
ISO/IEC 10646 revisions.  We propose to use the form <!UXXXXXXXX> 
where '!U' means "not 10646".

J.10) Subclause 5.1 is not in the scope of the standard.  It should be 
moved to a new informative annex.

J.11) The first sentence of the second paragraph of subclause 5.2.1:

"consists in" -> "consists of"

J.12) 5.2.1.1, Input parameters:

The description

	    - string1: referenced character string that is to be compared 
	to the reference string (string2)

	    - string2: reference character string that is to be compared 
	to the referenced string (string1)

should be changed to 

	    - string1: referenced character string that is to be compared 
	to the reference string (string2)

	    - string2: reference character string -- string serves as a base
	reference for comparison

J.13) 5.2.1.1, Output Parameter:

The name of the parameter "return" should be changed to "result".

J.14) 5.2.1.2:

The changes similar to J.12 and J.13 should be done.

J.15) 6. Conformance:

The definition of the conformance level here is different from the one in 
Clause 5. It should be aligned.

J.16) 7.1, Data Specification, 2nd para.

The sentence 

	Although the data in table 1 defines a specific ordering, it 
	should not be considered as an internationally acceptable default 
	ordering but only as a starting point for the tailoring process 
	prescribed in the next paragraph.

should be changed to

	The data in table 1 does not define a specific ordering. It
	should not be considered as an internationally acceptable default 
	ordering but only as a starting point for the tailoring process 
	prescribed in the next paragraph.

J.17) Annex 2 

It should be changed to informative with changing the first sentence from

	The benchmark shall be tested  in using the default table of 
	annex 1, adapted in defining the following toggles: PRIMNBSP, 
	ACCENTSONLATIN, PRIMIN

to 
	The benchmark should be tested when the default table of 
	annex 1 is tailored by defining the following toggles: PRIMNBSP, 
	ACCENTSONLATIN, PRIMIN. 

J.18) (not on FCD 14651) Japan supports the decision at Quebec meeting 
to eliminate the informative annex I in the first CD draft because the
annex misleads readers to think tailoring is a very complex process that 
almost always needs a visual interface.

_____________ end of Japan comments; beginning of Netherlands comments ___

The NNI votes NO on this FCD 14651 for the reasons detailed hereafter:

-1- The NNI is of the opinion that this document shows insufficient
    maturity to warrant an _F_CD.
-2- The structure, contents and wording of this document is considered to
    be below standards.  This is considered unacceptable.
-3- The editor has ignored the comments on the CD from the NNI. 
    This is equally unacceptable.

The NNI will change its vote into a yes vote only when all three issues
mentioned above and detailed hereafter will have been resolved
satisfactorily.
    
re 1:
Given the number of comments on the previous version of this document,
the NNI considers the stability of content and form of this document
insufficient to warrant its circulation as a FINAL CD. Given the comments
detailed hereafter, the NNI requests that at least one other CD be
circulated before another FCD can be attempted.

re 2:
The algorithm described has been partially detailed in the definition
clauses and in _in_formative annexes. The normative body of the document
does not contain a sufficient description of the algorithm.  The annexes
have been formulated as examples only. Although it will be not easy to
construct an appropriate abstract definition of the algorithm, the
document is considered incomplete without this.

The document contains English text that clearly has been translated
from French. Many remains from the French text are still visible.
These remains make the document difficult to understand.

re 3:

In our comments on the CD the NNI stated that:
  "The text of this standard leaves much to be desired
   regarding precision of definition, clarity of presentation ...
   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 the CD-registration,
   but found alas almost no improvement in this CD"

The Disposition of Comments sc22n2466 completely ignored our comment
by stating " This is purely ITTF matter ...."

However, sharpness of definition and clarity of presentation is not
an ITTF matter at all. It is the main task of a responsible editor.

The NNI feels very disappointed that apparently the editor of this document
is unable to write clearly (see below), is unfamiliar with programming 
language terminology and is unfamiliar with the mathematics behind 
programming languages but is even more so unable to read and 
understand the comments (not only ours, as can be seen clearly from the
DOC).

As we felt these shortcomings in definitions and presentation to 
be clearly visible to the intelligent reader, we refrained from
enumerating them.

This seems however not to have worked, so this time we will
give a _few_ examples from the clauses 3 and 5 of the document.
Please note that there is no use in making local repairs to the document.
The document should be totally checked and revised.

Comments will be given in-line with the text using question marks
or on separate lines preceded by a hash mark and a number.

Before starting with our comments on clauses 3 and 5 it should be noted
that 7 out of the 28 notions defined in clause 3 have not been used
in the document at all.

====================let's start here===================================

3 Definitions

API
                        Application Program Interface defined as a 
                        standardized application process describing the 
                        specifications of different procedures ...

#001# How can an API be defined as a STANDARDIZED APPLICATION PROCESS?
      It seems the editor is unfamiliar with the meaning of API and/or 
      APPLICATION.

#002# What is a process here; what is the difference between process 
      and procedure?

character string 
                        a series of characters concatenated in 
                        logical sequence

#003# It is unclear what makes a logical sequence; does the logical
      sequence of characters in a string differ from their physical
      sequence?

#004# This definition uses concatenation as if it was defined
      with the following signature:  
        Concatenation : Char x Char x Char x Char ...  -> CharString
      Thus is VERY unusual.

collating symbol 
                        a symbol used to specify weights assigned to a 
                        character in a symbolic fashion rather than
                        absolutely

#005# Absolute contrasts relative; symbolic contrasts real.

#006# In SC22 terminology "to assign" means that variables will be
involved; this however, seems not to be the case.

#007# What does it mean to "assign something in a symbolic fashion"?

#008# What does it mean to "assign something absolutely"?

collating element 
                        the smallest entity used to determine the logical
                        ordering of strings.

#009# What is a logical ordering of strings? how does it differ from
their physical ordering?

                        It normally consists of either a single character
                        or two or more characters collating as a single
                        entity

#010# This seems to mean that two strings can be ordered by one 
      single character?

#011# The "entity" at the beginning of this sentence seems to be of a
      different kind than the "entity" at the end of the sentence.

#012# What is the "not-normal" situation?

concatenation  
                        logical operation which consists in adding an
                        element at the end of a string to consider the
                        result as a new string, longer than the first one.

#013# What is a "logical" operation? Does it involve the logical
      connectives 'and', 'or', 'not'?

#014# In what sense is an "operation" different from a "process"?

#015# Concatenation has here been defined as of type:
        Concatenation : X-string x X -> X-String
        Instantiating X by Char gives a definition different from the
        earlier one.

equivalence   
                        in a comparison between two character strings,
                        a form of partial equality between the two
                        strings. After decomposition of the two strings in
                        different levels according to the ordering table
                        ...

#016# It is unclear that the ordering table describes a decomposition

#017# The ordering table is called elsewhere in this document: 
      - common template ordering table
      - Common Template order description
      - Common Template table
      - common template
      - International Common Template Table
    .... The typical case ...

#018# It is believed that examples should not be used in a definition
      clause

field                 for the purposes of this International Standard,
                      a single character string or any other data type
                      which may be ordered alone(?) or in conjunction
                      with other fields of a record, each field of a
                      record being compared to the same field of another
                      record;

#019# Is "a single character string" the same as 
         "a string containing one character" or 
         "a single string containing characters"?

#020# It is unclear how such a string can be ordered "alone"

#021# It is unclear what a "record" is; see later comment

#022# Precisely the "same" field? Perhaps corresponding?

#023# A data type (in SC22 terminology) can not be ordered; values of a
      data type may perhaps be ordered.
           
             in case of absolute equality of two equivalent fields,
             other fields of the records ....

#024# Yet another definition of equivalent? 

#025# What is absolute equality?
#026# It is believed that is not proper to distribute the description
      of the algorithm throughout the document.

first order token 
                        an absolute number used as a comparison element,
                        obtained out of tables for the first level that
                        describes a character; ...

#028# What kind of element is this?

#029# Absolute number; does this have the mathematical meaning of |x| ?

#030# It is unclear to what part of the sentence "that" refers to;
      the number, the element or the level?

#031# Does a level "describe" a character?

fourth order token 
                        an absolute number ....., obtained either out of,
                        or specifying  the position ....;
                        tokens of the fourth order level are always in
                        pairs the first token being a position, the second
                        one being a weight ...

#032# The first sub-sentence states that  a fourth order token consists 
      of "one" absolute number; the second sub-sentence states that 
      a fourth order token is a pair.

#033# The first sub-sentence states that a fourth order token is an 
      "either-or" the second sub-sentence states that it is a pair.

level   
                        Whenever used ....level .."key level" .."precision
                        level" ... conformance level...
                         normally ...

#034# Why such a difficult terminology? Why not just use precision level
      and conformance level throughout?

#035# What is the abnormal situation?

#036# It is again believed that it is not appropriate to detail the 
      algorithm here.

numeric relative value 
                        the relative .. in its final numeric and
                        processable form

#037# Are there non-final forms?
#038# Are there unprocessable forms?

ordering key  
                        a series of bits, the numerical value of which
                        determines its order;
                        to a character a ..... characters

#040# The second sub-sentence seems unconnected to the first one and is
      again discussing the algorithm

posthandling  
                        a process in which ... internally ... straightforward
                        comparisons ...

#041# What is a process?

#042# What is meant by internally? Internal to what?

#043# Why are the comparisons done according to this standard
      "straightforward"?

record   
                        the exhaustive structured set of fields that 
                        form a monolithic block in a file ....

#044# What is exhaustive here?

#045# In mathematics sets are unstructured. What is the structuring
      criterion?

#046# What is meant by monolithic?

#047# What is a block?

#048# What has a file to do with all this?

reference string ............ a base reference ..

#049# Are there also non-base references?

string   
                        a series of individual elements which form a whole,
                        when they are concatenated ...

#050# It seems that this definition disallows character strings
      consisting of a single character

transformation  
                        A(a?)n operation performed prior to comparison or
                        ordering ...

#051# What is the difference between comparison or ordering?

      This definition helps to have a more general discussion on the 
      terminology used in this standard.
      There are three verbs that are central to this standard: to order,
      to compare and to collate.
      Looking up the meanings of these verbs in this definition clause and 
      in a dictionary does not bring much light in the question of what the 
      precise definition used here is.
      Looking ahead in the document one finds that the API only allows for 
      comparisons to be done. 
      The mechanism is such that first strings are mapped to unique values
      (isomorphic to integers; what is called an injection in mathematics).
      These values are then compared using the underlying ordering of 
      the set of integers.
      The fact that the strings can then be (re)ordered seems to be outside
      the scope of this standard.
      Collation has not defined here at all. Looking up its meaning in
      Webster's gives again 'to compare' and 'to order', but does not give
      any insight.

5.1 Prehandling phase ...

This requirement shall be met for conformance levels greater than 1

#052# This requirement -> The requirement specified in this clause ...

#053# Conformance requirements have been indicated by letters!

It is recommended ..

#054# This recommendation conflicts with "shall" in the first sentence.

#055# But, this whole sentence seems misplaced here.

The symbolic table, ...

#056# No symbolic table has been provided in this document shall be
provided in a numeric form 

#057# What kind of numeric form? floating point numbers?
.... each element of the matrix being a numerical token indicating 
one or more relative weights.

#058# Numerical token has not been defined

#059# Relative weight has not been defined

#060# Can "one" token indicate "more than one" weights?

#061# What is the meaning of "to indicate a weight"? As a balance?

#062# Generally speaking, it seems somewhat of an overspecification to
require that the table be built in a particular(matrix) form (n *m array).
As long as the outcome of the comparison of two strings conforms to the 
requirements of this standard, the internal form used for data seems not
significant.

However(,?) the values used shall respect the order specified in the 
symbolic table data.

#063# No symbolic table can be found in this document.

Conformance level C requires that the API shall allow to choose a table
built at a preceding time

#064# What is "a preceding time"? Earlier than prehandling? 

It may be necessary to transform a field of a record 

#065# Into what?
... or to transform unstructured records

#066# What are "unstructured" records? Please note the definition of records 
  in clause 3
... into structured fields 

#067# Given the definitions of record and field in clause 3 this 
      definition is incomprehensible
... before the actual process can begin.

#068# Yet another process?
The implementer is responsible for ensuring ...

#068# The implementer of this standard? How can that be?
This is a global operation

#069# What is meant by global?

#070# So an operation is a process?
that may involve "exploding" records before ordering them

#071# How does one explode an "exhaustive structured set" or 
      a "monolithic block"?

#072# Are these records ordered, or are the strings ordered?
Therefore, the prehandling phase ...

#073# Why a conclusion here?
Thus, prehandling is not part of the comparison operation API.

#074# Why a conclusion here? We already knew that.
The comparison API will not contain any default method related to
prehandling.

#075# What is a default method?

#076# Isn't this derivable from the previous sentence?
...for allowing the use of this IS in higher layers of the application?

#077# It seems inappropriate for this standard to state anything about
the structuring of an application using this standard.

The prehandling phase ... transform the actual coded characters used on
input

#078# In the previous section it was said that prehandling operated on
records?
....Then the prehandling phase can correspond to the empty process

#079# So a phase is equal to a process?
Ideally, all control characters

#080# Ideally = shall/recommended/optional ?

#081# Elsewhere, control characters have been named control functions
.. in case of absolute homography ...

#082# Homography between ? and ?

#083# Homography means "equal in writing"; what is absolute equal in
writing?
... in the common template

#084# No common template can be found in this document

5.2.1 ....

The general interface consists in (of?) three ...

#085# Is there a specific interface too?

#086# Several typos here

#087# It is unclear why these procedures have been numbered

#088# It is unclear how CARABIN can _produce_ a _PRE_fabricated bit
string.

#089# It is unclear whether there are bit strings that are 
      processable indirectly.

The implementer may choose appropriate values for the application.

#090# The implementer of this API chooses values for an application 
      he does not know anything about?

#091# General remark: As far as understood, all three 'procedures' are 
      effectively functions (ie they have no side-effect).
      It is unclear why they are called procedures then.

5.2.1.1 .....
table .... If this parameter is not provided, the common template 
will be assumed.

#092# It is unclear how this should be implemented in a language 
      that requires all the parameters being present.

COMPCAR process:
This procedure shall be processed to give results equivalent to the
following:
This procedure shall be processed to give results equivalent to the
following:

#093# Two times the same sentence

#094# Yet another use of equivalent

#095# Process or procedure?

Submit character strings string1 and string 2 and table 'table' to
procdure CARABIN ...

#096# CARABIN does not have such parameters.
      After having looked up the definitions, it is clear what has been 
      intended, why not describe it precisely?
Execute procedure ....

#097# Perhaps process the procedure?

A minimum interface for conformance level A or B can very well(?) use 
the standard C-language function model of ...

#098# Why "minimum"?

#099# The C-language has no notion of function model

This limited interface ...

#100# Is a limited interface the same as a minimum interface?

COMPBIN process:
.... coded character strings ..

#101# Undefined notion
... octet by octet ...

#102# Unclear what octets have to do here

5.2.1.3.
....to a comparable bit strings

#103# All bit strings are comparable, aren't they?

... not to compile this table 'table' every time this function is called.

#104# It is unclear what compilation model is used here. 
      Is this compilation the the same as the earlier mentioned
      prehandling?

____________ end of Netherlands comments; beginning of Sweden comments ___

Swedish ballot comments on ISO/IEC FCD 14651.2 (SC22 N 2607)

As an O-member Sweden submits following comments for consideration. If
not the comments are not considered. Sweden may vote NO on the FDIS.

MAJOR comments

Each of the following points must be satisfactorily resolved, and
implemented in the next draft, in order to turn a possible NO vote at FDIS
level into a yes vote.

All API requirements MUST be completely removed.

It must be possible to follow the International String Ordering standard,
or base national string ordering standards on it, WITHOUT requiring
implementations to provide a particular API.  Secondly, before
standardising on a new API for this there should be considerable
experience and consensus on how it should work.  This is not yet achieved.
In either case a string ordering API must be moved to another later
standard, if standardised at all.

All FILE FORMAT (14652 or other) requirements MUST be completely removed.
It must be possible to follow the International String Ordering standard,
or base national string ordering standards on it, WITHOUT requiring
implementations to provide or use a particular file format.

All other dependencies on ISO/IEC 14652 must also be removed, including
the normative reference. Those wishing to follow 14651 should NOT be
forced to also follow 14652. Combining non-spacing characters, as well as
other canonical equivalences (in the Unicode 2.0 sense) in general, MUST
be handled properly.

I.e. character sub-sequences that are canonically equivalent according to
Unicode 2.1 MUST be regarded as equivalent at all "levels" (in the 14651
sense) when compared as text (i.e. character) strings according to ISO/IEC
14651.

The easiest way to do this is to do full canonical decomposition and
combining marks canonical reordering according to Unicode 2.0.

An appropriate table of (full) canonical decompositions is publicly
available from the Unicode consortium, and should be a normative table in
an annex of 14651.  This must include the algorithmic decomposition of
Hangul syllables into conjoining Hangul Jamo. (See also comment 9 below
on Japanese.)

Compatibility equivalent (in the Unicode 2.0 sense) sub-sequences must be
regarded as different ONLY at the least significant "level" ("level 4"),
NOT at any more significant level.  E.g. level 3 should only handle "case"
variants, no other kind of variation (like full-width/half-width) which
is not based on orthographic needs, only on backward compatibility needs.

An appropriate table of (full) compatibility decompositions is publicly
available from the Unicode consortium, and should be a normative table in
an annex of 14651.

14651 must cover all scripts and characters currently covered by Unicode
2.1 and 10646 including all amendments to date. The current draft misses
many scripts.  It is our understanding that the Unicode consortium can
provide fuller tables, covering all scripts currently in 10646.

Arabic: The suggestion (annex C, and annex 1 p. 94) that the Arabic
presentation forms are stored in a different order than the nominal
characters for Arabic must be removed (it is false).

Thai and Lao: The standard should, however, take into account the
"visual", rather than "logical", storage order for Thai and Lao
characters, and require pre-processing to order them "logically" before
key construction.

Japanese:
The half-width voiced marks must be considered combining with the
preceding half-width Katakana character (to get correct collation).  This
affects the mapping from compatibility characters to nominal characters.

Prolonged sound marks: These take on different weights depending on the
preceding kana letter. Repeat/iteration marks: Again, our understanding is
that these should take on different weights depending on the preceding
kana letter. 

Kanji digits (including "fraud-proof forms"), 0-9: These should be handled like other digits.  However,
handling of ideographs for "ten", "hundred", etc., need not be done by default.
Make certain "old" Katakana sort together with "modern" spellings (va, ve, vi, vo).

The standard should explicitly allow for "transliterative" collation.
I.e. the collation is primarily done on transliterated strings (whether
manually, "pronunciation field", semi-automatically, or automatically
derived), and only to a lesser degree depend on the direct input/output
strings (which should not be completely ignored).  This would be useful
for "pronunciation" collation often used for Korean and Japanese, or
indeed even for "phonebook" collation.  I.e., levels 1-3 would be levels
1-3 on the transliterated string, and levels 4-6 would be levels 1-3 on
the original string, level 7 would be level 4 of the original string.

Sequences of (base ten) digits, up to a settable length (n) which is at
least five, in the same script must by default be pre-processed to include
leading zeroes so that the length of the digit sequence is n digits
long.

By default, we limit this to natural numbers written as ordinary base ten
numerals.  A tailored version may do something more fancy.

Each digit is given a weight that in some way corresponds to its
(individual) decimal value, irrespective of script.  The weight is such
that all digits are collated after all alphabetical or ideographic
characters).  Periods and digits are to be collated after spaces (if
spaces are not ignored).  

We would then, without any tailoring, get the expected ordering of
strings like these:
     1. Intro
     1.1 bbbb
     2. dsfsdfsdf
     2.1 fsdfds
     2.2 sdfsfsd
     ...
     2.11 dfsd
     2.11.1 vxvxcv
     3 vxcvxc
     3.1 dfsf
     ...
     10. cvsdf
     11. sdfsda

Many things are sequence numbered (and sub-sequence numbered) just like
this.  It would be a bad idea if they by default came out in the wrong
order, and additional effort had to be made every time such strings needed
to be properly ordered.

14651 must make ordering compromises ONLY if there is a need to
compromise among existing nationally/linguistically acceptable orderings
(transliteration aside).  This means that for many scripts,
one would not, if this principle were followed, need to specify any
national variation.

The normative reference to the programming language C must be removed.
There must be no requirement that one must use C as the programming
language.

Many programming languages can be used and there is no reason to single
out C, even it is used in an example (which should be deleted).  Indeed,
with the deletion of the API part, there is no need to refer to any
programming language at all, even for examples.

The notion of "posthandling" must be removed since no posthandling is, or
need be, specified in this standard.

All non-empty sequences of space characters (there are about 10-20
different character codes), paragraph separators, line separators, C0, and
C1 "control characters" must be regarded as equivalent at all but the last
"level", and regarded as either a single space or be ignored.  Even if
not in general ignored, they should be ignored for collation purposes at
all but the last level if they occur in the very beginning of a string.
(This can be handled by the pre-processing.)

There is no normative mathematical description on how the comparison keys
for strings are constructed from the (symbolic) weights for individual
characters.  

There is an informal description (annex C), but it is very incomplete,
imprecise and based on some strange but weak implementation experience.
The current draft is far from satisfactory in describing the string
ordering and how it depends on the weight tables and other data.  What is
needed is a mathematically precise specification, so that we have a firm
semantics for "multi-level" string collation.

Map each (pre-processed) string to a value in R (the mathematical "real"
numbers), in such a way that the values mapped to are ordered, in R, in
the same way that the strings should be ordered. The standard should allow
implementations to use any strictly monotonically increasing mapping from
the specified values in R to other values in R that can be more compactly
represented.  The standard need not normatively specify any such mapping,
but can give a few as examples (it is our understanding that the Unicode
consortium can provide a few representations).  The Swedish NB can
help with the detailed specifications of the mapping from strings to R
(using tabulated character weights, whether symbolic, as in the current
annex 1, or direct), and example strictly monotonous mappings from R to R.

Parsing strings into "lines"/"records" and "fields" (or any other
structure) must be considered out of scope for this standard.  If done, it
would be done prior to, not included with, collation proper. The major
comments above, and the minor comments below, strongly indicate the need
to rewrite the entire text from scratch.  We see no way in which minor
changes here and there can correct the collection of errors, omissions,
and misdirected requirements contained in the current text.  Suggested
table of contents:
1. Scope [see below]
2. Conformity [see below]
3. Normative references [only 10646]
4. Symbols and Definitions [see below]
5. Multi-level string ordering
   5.1 Included pre-processing [canonical equiv., digit seq., etc.]
   5.2 The levels
   5.3 The weights
   5.4 Symbolic weights
   5.5 Basic key construction from weights [mathematical description]
   5.6 Strictly monotonic mappings of keys [allowance, not details]
6. Tailoring of the string ordering [how it would work; what can be done]
7. Transliterative string ordering
8. Additional explanation about the collation tables [format of tables
   not normative except for the standard itself]

Annex A (normative): Combining non-spacing marks.
Annex B (normative): Canonical decomposition, and canonical reordering.
Annex C (normative): Compatibility decomposition. [+special for
                     half-width voiced marks]
Annex D (normative): Thai and Lao reordering for collation.
Annex E (normative): Multi-level character weights.
Annex F (informative): Rationale for multi-level string collation.
Annex G (informative): Example collations. [NOT normative]
Annex H (informative): Example suitable monotonically increasing mappings.
               [NOT normative]
Annex J (informative): Example collation tailorings. [at least one
               complete example]

It is our understanding that the US NB may present other major comments,
e.g. regarding such things as the principles by which the weight tables
are constructed, that we too may support as major.

Minor comments

The comments in this section are recommendations for change, but do not
one by one constitute reason for a no vote.  Taken together, however, they
strongly indicate the need to completely rewrite the entire text of 14651
from scratch.  Since we do suggest a complete rewrite, there are no
references to specific sentences in the comments below.  Rather, it is a
number of items for the editor to keep in mind when writing the new text.

Change the title.  Suggestion: "International string ordering _
Multi-level collation method and international compromise string order".

Section 1: Please make two fairly detailed lists: one with items that are
in scope for this standard, and one with items that are, or could be seen
as, related, but that are out of scope. The first list (in scope) would
include items such as 

An internationally acceptable collation order for strings that include
characters that are normally not used in a particular region.

Compromises between (expected) national collation orders for strings with
scripts used for many  languages and/or conventions of collation.

Certain pre-processing (internal to the collation) to obtain actual
strings to compare.  The pre-processing can reorder certain characters,
and replace sub-strings by equivalent, but canonical, sub-strings.

Proper handling of combining sequences of characters.

Transliterative collation, where the transliteration itself is external
to the collation.

The second list (out of scope) would include items such as: 
Application programming interface (API) for invoking string comparison or
collation.
File formats for specifying collation order to an actual implementation.
Parsing of a string to obtain sub-strings to collate.
Escape-sequence or control code interpretation.
National variations from the compromise string ordering (national
standards are expected to cover these).

There should be an informative annex indicating at least one complete,
medium complex example national tailoring (which of course is/are not
normative even for the nation(s) taken as examples). All examples and side
remarks must be made into "Note"s, to clarify their non-normative nature. 
(Since we suggest a complete rewrite, we see no point in listing the ones
in the current text here, but the editor should keep this in mind when
writing the new text.)

Section 3: "API" is out of scope and should not occur in the definition
list.

Section 3: "character string"; strange definition, in what sense
"logical"?

Section 3: "concatenation"; strange definition, in what sense "logical"?

Section 3: "equivalence"; the text there constitutes a lot of ranting
about string comparison, but contains no definition of 'equivalence'.

Section 3: "field"; this is out of scope for this standard.

Section 3: "posthandling"; no such thing is specified, nor need be
specified, by this standard.

Section 3: "record"; this is out of scope for this standard.

Section 3: "reference/referenced string"; bad terminology, please do not
use it.

Section 3: "procedure"; this is out of scope for this standard.

Section 3: "transformation"; the text there constitutes a lot of ranting
about string comparison, but contains no definition of 'transformation'.

Section 5: OUT OF SCOPE, DELETE.  See above.

Section 6: Rewrite completely, current one refers only to out-of scope
material.

Other sections: see major comment 16.

B.t.w.: We can do without the cryptic symbolic weight/script names (like
"Hy" for Armenian, and "a8" for "a's weight" (having a very American
pun)).

______ end of Sweden comments; beginning of UK comments _______________

From: Suzanne Davison <[email-masked])

Subject: UK Ballot Response to SC22 N2607 ISO/IEC FCD 147651

Dear Bill,

As indicated in my e-mail of 30 April, the UK's Vote on the above
FCD is DISAPPROVAL backed by the comments which follow: 

Subject: ISO/IEC FCD 14651, Annex A:
inconsistencies in Greek

UK Comments accompanying DISAPPROVAL vote: 

In Annex A there are inconsistencies between the full listing of
accented Greek characters, and the listing of Greek characters in
earlier parts of Annex A.

The full listing of accented Greek characters (indicated at the end
of this comment) seems to be the most consistent and would be
adopted: other parts should be corrected as indicated below.

Excerpts from Annex A, observing the same order given there, with
notes.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
collating-symbol <TONOS> % tonos
collating-symbol <PSILI> % psili
...

        tonos normally near the end of the sequence, not at the
        beginning

collating-symbol <PSILI+VARIA>
collating-symbol <VARIA+YPOGE>
collating-symbol <VARIA+DIALY>
collating-symbol <OXIAA> % oxia
collating-symbol <OXIAA+YPOGE>
collating-symbol <OXIAA+DIALY>
collating-symbol <PERIS> % perispomeni
collating-symbol <PERIS+YPOGE>
collating-symbol <YPOGE> % ypogegrammeni
collating-symbol <PROSG> % prosgegrammeni
collating-symbol <DIALY> % dialytika
collating-symbol <DIALY+PERIS>
collating-symbol <DIALY+TONOS>
...

        Dialytika is normally the initial grouping, not secondary
        grouping. Some of the names above also reflect this
        inconsistency.

<TONOS>
<PSILI>
...

        TONOS is normally near the end of the seqeunce, not at the
        beginning

<PSILI+VARIA>
<VARIA>
<VARIA+YPOGE>
<VARIA+DIALY>
<OXIAA>
<OXIAA+YPOGE>
<OXIAA+DIALY>
<PERIS>
<PERIS+YPOGE>
<TONOS>
<YPOGE>
<PROSG>
<DIALY>
<DIALY+TONOS>
<DIALY+PERIS>
...

        DIALYTIKA normally the initial grouping, not secondary
        grouping

% Accents

        Several of these characters are dual-purpose Latin/Greek
        combining accents. Could this lead to any complications in
        mixed Latin/Greek text?

<U00B4> IGNORE;IGNORE;IGNORE;<U00B4> % ACUTE ACCENT
<U02CA> IGNORE;IGNORE;IGNORE;<U02CA> % MODIFIER LETTER ACUTE ACCENT
<U0301> IGNORE;IGNORE;IGNORE;<U0301> % COMBINING ACUTE ACCENT (Oxia)
<U0060> IGNORE;IGNORE;IGNORE;<U0060> % GRAVE ACCENT
<U02CB> IGNORE;IGNORE;IGNORE;<U02CB> % MODIFIER LETTER GRAVE ACCENT
<U0300> IGNORE;IGNORE;IGNORE;<U0300> % COMBINING GRAVE ACCENT (Varia)
<U02D8> IGNORE;IGNORE;IGNORE;<U02D8> % BREVE
<U0306> IGNORE;IGNORE;IGNORE;<U0306> % COMBINING BREVE (Vrachy)
<U00A8> IGNORE;IGNORE;IGNORE;<U00A8> % DIAERESIS
<U0308> IGNORE;IGNORE;IGNORE;<U0308> % COMBINING DIAERESIS (Dialytika)
<U00B7> IGNORE;IGNORE;IGNORE;<U00B7> % MIDDLE DOT
<U1FBF> IGNORE;IGNORE;IGNORE;<U1FBF> % GREEK PSILI
<U0313> IGNORE;IGNORE;IGNORE;<U0313> % COMBINING COMMA ABOVE (Psili)
<U0486> IGNORE;IGNORE;IGNORE;<U0486> % CYRILLIC COMBINING PSILI PNEUMATA
<U1FCD> IGNORE;IGNORE;IGNORE;<U1FCD> % GREEK PSILI AND VARIA
<U1FCE> IGNORE;IGNORE;IGNORE;<U1FCE> % GREEK PSILI AND OXIA
<U1FCF> IGNORE;IGNORE;IGNORE;<U1FCF> % GREEK PSILI AND PERISPOMENI
<U1FFE> IGNORE;IGNORE;IGNORE;<U1FFE> % GREEK DASIA
<U0314> IGNORE;IGNORE;IGNORE;<U0314> % COMBINING REVERSED COMMA ABOVE
(Dasia)
<U0485> IGNORE;IGNORE;IGNORE;<U0485> % CYRILLIC COMBINING DASIA PNEUMATA
<U1FDD> IGNORE;IGNORE;IGNORE;<U1FDD> % GREEK DASIA AND VARIA
<U1FDE> IGNORE;IGNORE;IGNORE;<U1FDE> % GREEK DASIA AND OXIA
<U1FDF> IGNORE;IGNORE;IGNORE;<U1FDF> % GREEK DASIA AND PERISPOMENI
<U1FEF> IGNORE;IGNORE;IGNORE;<U1FEF> % GREEK VARIA
<U1FFD> IGNORE;IGNORE;IGNORE;<U1FFD> % GREEK OXIA
<U0384> IGNORE;IGNORE;IGNORE;<U0384> % GREEK TONOS
...
        In most accented characters below, TONOS follows
PERISPOMENI.
        Here, just above, it appears out of order.

<U030D> IGNORE;IGNORE;IGNORE;<U030D> % COMBINING VERTICAL LINE ABOVE
(Tonos)
<U1FC0> IGNORE;IGNORE;IGNORE;<U1FC0> % GREEK PERISPOMENI
<U1FBE> IGNORE;IGNORE;IGNORE;<U1FBE> % GREEK PROSGEGRAMMENI
<U037A> IGNORE;IGNORE;IGNORE;<U037A> % GREEK YPOGEGRAMMENI
<U1FED> IGNORE;IGNORE;IGNORE;<U1FED> % GREEK DIALYTIKA AND VARIA
<U1FEE> IGNORE;IGNORE;IGNORE;<U1FEE> % GREEK DIALYTIKA AND OXIA
<U0385> IGNORE;IGNORE;IGNORE;<U0385> % GREEK DIALYTIKA TONOS

        In most accented characters below, DIALYTIKA AND TONOS
        follows DIALYTIKA AND PERISPOMENI. Here, just above, it
        appears out of order.

<U1FC1> IGNORE;IGNORE;IGNORE;<U1FC1> % GREEK DIALYTIKA AND PERISPOMENI
<U02D0> IGNORE;IGNORE;IGNORE;<U02D0> % MODIFIER LETTER TRIANGULAR COLON
%
order_start <El>;forward;forward;forward;forward,position
%

        This section below, and accented letters listed under other
        vowels, appears to show the correct ordering.

<U0391> <alpha8>;<BLANK>;<CAP>;IGNORE % GREEK CAPITAL LETTER ALPHA
<U03B1> <alpha8>;<BLANK>;<MIN>;IGNORE % GREEK SMALL LETTER ALPHA
<U1FB8> <alpha8>;<VRACH>;<CAP>;IGNORE % GREEK CAPITAL LETTER ALPHA WITH
VRACHY
<U1FB0> <alpha8>;<VRACH>;<MIN>;IGNORE % GREEK SMALL LETTER ALPHA WITH
VRACHY
<U1FB9> <alpha8>;<MACRO>;<CAP>;IGNORE % GREEK CAPITAL LETTER ALPHA WITH
MACRON
<U1FB1> <alpha8>;<MACRO>;<MIN>;IGNORE % GREEK SMALL LETTER ALPHA WITH
MACRON
<U1F08> <alpha8>;<PSILI>;<CAP>;IGNORE % GREEK CAPITAL LETTER ALPHA WITH
PSILI
<U1F00> <alpha8>;<PSILI>;<MIN>;IGNORE % GREEK SMALL LETTER ALPHA WITH
PSILI
<U1F0A> <alpha8>;<PSILI+VARIA>;<CAP>;IGNORE % GREEK CAPITAL LETTER ALPHA
WITH PSILI AND VARIA
<U1F02> <alpha8>;<PSILI+VARIA>;<MIN>;IGNORE % GREEK SMALL LETTER ALPHA
WITH PSILI AND VARIA
<U1F8A> <alpha8>;<PSILI+VARIA+PROSG>;<CAP>;IGNORE % GREEK CAPITAL LETTER
ALPHA WITH PSILI AND VARIA AND PROSGEGRAMMENI
<U1F82> <alpha8>;<PSILI+VARIA+YPOGE>;<MIN>;IGNORE % GREEK SMALL LETTER
ALPHA WITH PSILI AND VARIA AND YPOGEGRAMMENI
<U1F0C> <alpha8>;<PSILI+OXIAA>;<CAP>;IGNORE % GREEK CAPITAL LETTER ALPHA
WITH PSILI AND OXIA
<U1F04> <alpha8>;<PSILI+OXIAA>;<MIN>;IGNORE % GREEK SMALL LETTER ALPHA
WITH PSILI AND OXIA
<U1F8C> <alpha8>;<PSILI+OXIAA+PROSG>;<CAP>;IGNORE % GREEK CAPITAL LETTER
ALPHA WITH PSILI AND OXIA AND PROSGEGRAMMENI
<U1F84> <alpha8>;<PSILI+OXIAA+YPOGE>;<MIN>;IGNORE % GREEK SMALL LETTER
ALPHA WITH PSILI AND OXIA AND YPOGEGRAMMENI
<U1F0E> <alpha8>;<PSILI+PERIS>;<CAP>;IGNORE % GREEK CAPITAL LETTER ALPHA
WITH PSILI AND PERISPOMENI
<U1F06> <alpha8>;<PSILI+PERIS>;<MIN>;IGNORE % GREEK SMALL LETTER ALPHA
WITH PSILI AND PERISPOMENI
<U1F8E> <alpha8>;<PSILI+PERIS+PROSG>;<CAP>;IGNORE % GREEK CAPITAL LETTER
ALPHA WITH PSILI AND PERISPOMENI AND PROSGEGRAMMENI
<U1F86> <alpha8>;<PSILI+PERIS+YPOGE>;<MIN>;IGNORE % GREEK SMALL LETTER
ALPHA WITH PSILI AND PERISPOMENI AND YPOGEGRAMMENI
<U1F88> <alpha8>;<PSILI+PROSG>;<CAP>;IGNORE % GREEK CAPITAL LETTER ALPHA
WITH PSILI AND PROSGEGRAMMENI
<U1F80> <alpha8>;<PSILI+YPOGE>;<MIN>;IGNORE % GREEK SMALL LETTER ALPHA
WITH PSILI AND YPOGEGRAMMENI
<U1F09> <alpha8>;<DASIA>;<CAP>;IGNORE % GREEK CAPITAL LETTER ALPHA WITH
DASIA
<U1F01> <alpha8>;<DASIA>;<MIN>;IGNORE % GREEK SMALL LETTER ALPHA WITH
DASIA
<U1F0B> <alpha8>;<DASIA+VARIA>;<CAP>;IGNORE % GREEK CAPITAL LETTER ALPHA
WITH DASIA AND VARIA
<U1F03> <alpha8>;<DASIA+VARIA>;<MIN>;IGNORE % GREEK SMALL LETTER ALPHA
WITH DASIA AND VARIA
<U1F8B> <alpha8>;<DASIA+VARIA+PROSG>;<CAP>;IGNORE % GREEK CAPITAL LETTER
ALPHA WITH DASIA AND VARIA AND PROSGEGRAMMENI
<U1F83> <alpha8>;<DASIA+VARIA+YPOGE>;<MIN>;IGNORE % GREEK SMALL LETTER
ALPHA WITH DASIA AND VARIA AND YPOGEGRAMMENI
<U1F0D> <alpha8>;<DASIA+OXIAA>;<CAP>;IGNORE % GREEK CAPITAL LETTER ALPHA
WITH DASIA AND OXIA
<U1F05> <alpha8>;<DASIA+OXIAA>;<MIN>;IGNORE % GREEK SMALL LETTER ALPHA
WITH DASIA AND OXIA
<U1F8D> <alpha8>;<DASIA+OXIAA+PROSG>;<CAP>;IGNORE % GREEK CAPITAL LETTER
ALPHA WITH DASIA AND OXIA AND PROSGEGRAMMENI
<U1F85> <alpha8>;<DASIA+OXIAA+YPOGE>;<MIN>;IGNORE % GREEK SMALL LETTER
ALPHA WITH DASIA AND OXIA AND YPOGEGRAMMENI
<U1F0F> <alpha8>;<DASIA+PERIS>;<CAP>;IGNORE % GREEK CAPITAL LETTER ALPHA
WITH DASIA AND PERISPOMENI
<U1F07> <alpha8>;<DASIA+PERIS>;<MIN>;IGNORE % GREEK SMALL LETTER ALPHA
WITH DASIA AND PERISPOMENI
<U1F8F> <alpha8>;<DASIA+PROSG>;<CAP>;IGNORE % GREEK CAPITAL LETTER ALPHA
WITH DASIA AND PERISPOMENI AND PROSGEGRAMMENI
<U1F87> <alpha8>;<DASIA+YPOGE>;<MIN>;IGNORE % GREEK SMALL LETTER ALPHA
WITH DASIA AND PERISPOMENI AND YPOGEGRAMMENI
<U1F89> <alpha8>;<DASIA+PROSG>;<CAP>;IGNORE % GREEK CAPITAL LETTER ALPHA
WITH DASIA AND PROSGEGRAMMENI
<U1F81> <alpha8>;<DASIA+YPOGE>;<MIN>;IGNORE % GREEK SMALL LETTER ALPHA
WITH DASIA AND YPOGEGRAMMENI
<U1FBA> <alpha8>;<VARIA>;<CAP>;IGNORE % GREEK CAPITAL LETTER ALPHA WITH
VARIA
<U1F70> <alpha8>;<VARIA>;<MIN>;IGNORE % GREEK SMALL LETTER ALPHA WITH
VARIA
<U1FB2> <alpha8>;<VARIA+YPOGE>;<MIN>;IGNORE % GREEK SMALL LETTER ALPHA
WITH VARIA AND YPOGEGRAMMENI
<U1FBB> <alpha8>;<OXIAA>;<CAP>;IGNORE % GREEK CAPITAL LETTER ALPHA WITH
OXIA
<U1F71> <alpha8>;<OXIAA>;<MIN>;IGNORE % GREEK SMALL LETTER ALPHA WITH OXIA
<U1FB4> <alpha8>;<OXIAA+YPOGE>;<MIN>;IGNORE % GREEK SMALL LETTER ALPHA
WITH OXIA AND YPOGEGRAMMENI
<U1FB6> <alpha8>;<PERIS>;<MIN>;IGNORE % GREEK SMALL LETTER ALPHA WITH
PERISPOMENI
<U1FB7> <alpha8>;<PERIS+YPOGE>;<MIN>;IGNORE % GREEK SMALL LETTER ALPHA
WITH PERISPOMENI AND YPOGRAMMENI
<U0386> <alpha8>;<TONOS>;<CAP>;IGNORE % GREEK CAPITAL LETTER ALPHA WITH
TONOS
<U03AC> <alpha8>;<TONOS>;<MIN>;IGNORE % GREEK SMALL LETTER ALPHA WITH
TONOS
<U1FBC> <alpha8>;<PROSG>;<CAP>;IGNORE % GREEK CAPITAL LETTER ALPHA WITH
PROSGEGRAMMENI
<U1FB3> <alpha8>;<YPOGE>;<MIN>;IGNORE % GREEK SMALL LETTER ALPHA WITH
YPOGEGRAMM
ENI
...

____________ end of UK comments; beginning of USA comments _________

 The US National Body votes to Disapprove SO/IEC FCD 14651, Information
 technology - International String Ordering and Comparison - Method for
 Comparing Character Strings and Description of the Common Template
 Tailorable Ordering.  
 
 Comments:
 
 The Conformance clause of 14651 "must not mandate:
 - more than 3 customizable levels
 - the use of the precise data or tailoring format specified
 - the use of the precise API specified"

 The International Common Template Table must incorporate all of the
 corrections for syntax errors and other problems reported by Ken
 Whistler to the Editor.  These corrections are required in order for
 the Table to even be machine processed at all.
 
 Furthermore, the U.S. strongly prefers that the content of the   
 International Common Template Table be inclusive of the *entire*
 content of ISO/IEC 10646-1 through Amendment 7 (Collection 30),
 rather than an arbitrary and otherwise unidentified subset of 10646.
 The best way to accomplish this is to replace the content of Annex 1
 with the symbolic information in the symdump2.txt table provided by
 Ken Whistler to the Editor. This would have the additional advantag
 of aligning the content of the International Common Template Table
 with the default table in use by vendors which implement the Unicode
 Collation Algorithm.
 
 The International Common Template Table must be published in
 machine-readable format to be usable for implementation.
 
 An expert contribution to WG20 from the US is being prepared 
 for the WG20 meeting in June 1998.

_________________ end of SC22 N2719 __________________________________

                                                                                                                                                                                                                                  !

                                                                                                                                                                                                                                  !

                                                                                                                                                                                                                                  !

                                                                                                                                                                                                                                  !

                                                                                                                                                                                                                                  !

                                                                                                                                                                                                                                  !

                                                                                                                                                                                                                                  !

                                                                                                                                                                                                                                  !

                                                                                                                                                                                                                                  !

                                                                                                                                                                                                                                  !

                                                                                                                                                                                                                                  !

                                                                                                                                                                                                                                  !

                                                                                                                                                                                                                                  !

                                                                                                                                                                                                                                  !

  [ Part 2: "Attached Text" ]

The NNI votes NO on this FCD 14651 for the reasons detailed hereafter:

-1- The NNI is of the opinion that this document shows insufficient
    maturity to warrant an _F_CD.
-2- The structure, contents and wording of this document is considered to
    be below standards.  This is considered unacceptable.
-3- The editor has ignored the comments on the CD from the NNI. 
    This is equally unacceptable.

The NNI will change its vote into a yes vote only when all three issues
mentioned above and detailed hereafter will have been resolved satisfactorily.
    
re 1:
Given the number of comments on the previous version of this document, the
NNI considers the stability of content and form of this document
insufficient to warrant its circulation as a FINAL CD.
Given the comments detailed hereafter, the NNI requests that at least one
other CD be circulated before another FCD can be attempted.

re 2:
The algorithm described has been partially detailed in the 
definition clauses and in _in_formative annexes. 
The normative body of the document does not contain a sufficient description 
of the algorithm.  The annexes have been formulated as examples only.
Although it will be not easy to construct an appropriate abstract
definition of the algorithm, the document is considered incomplete without
this.

The document contains English text that clearly has been translated
from French. Many remains from the French text are still visible.
These remains make the document difficult to understand.

re 3:

In our comments on the CD the NNI stated that:
  "The text of this standard leaves much to be desired
   regarding precision of definition, clarity of presentation ...
   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 the CD-registration,
   but found alas almost no improvement in this CD"
The Disposition of Comments sc22n2466 completely ignored our comment
by stating " This is purely ITTF matter ...."
However, sharpness of definition and clarity of presentation is not
an ITTF matter at all. It is the main task of a responsible editor.

The NNI feels very disappointed that apparently the editor of this document
is unable to write clearly (see below), is unfamiliar with programming 
language terminology and is unfamiliar with the mathematics behind 
programming languages but is even more so unable to read and 
understand the comments (not only ours, as can be seen clearly from the DOC).

As we felt these shortcomings in definitions and presentation to 
be clearly visible to the intelligent reader, we refrained from
enumerating them.
This seems however not to have worked, so this time we will
give a _few_ examples from the clauses 3 and 5 of the document.
Please note that there is no use in making local repairs to the document.
The document should be totally checked and revised.

Comments will be given in-line with the text using question marks
or on separate lines preceded by a hash mark and a number.

Before starting with our comments on clauses 3 and 5 it should be noted
that 7 out of the 28 notions defined in clause 3 have not been used
in the document at all.

====================let's start here===================================

3 Definitions

API
                        Application Program Interface defined as a 
                        standardized application process describing the 
                        specifications of different procedures ...
#001# How can an API be defined as a STANDARDIZED APPLICATION PROCESS?
      It seems the editor is unfamiliar with the meaning of API and/or 
      APPLICATION.
#002# What is a process here; what is the difference between process 
      and procedure?

character string 
                        a series of characters concatenated in 
                        logical sequence
#003# It is unclear what makes a logical sequence; does the logical sequence 
      of characters in a string differ from their physical sequence?
#004# This definition uses concatenation as if it was defined
      with the following signature:  
        Concatenation : Char x Char x Char x Char ...  -> CharString
      Thus is VERY unusual.

collating symbol 
                        a symbol used to specify weights assigned to a 
                        character in a symbolic fashion rather than absolutely
#005# Absolute contrasts relative; symbolic contrasts real.
#006# In SC22 terminology "to assign" means that variables will be involved; 
      this however, seems not to be the case.
#007# What does it mean to "assign something in a symbolic fashion"?
#008# What does it mean to "assign something absolutely"?

collating element 
                        the smallest entity used to determine the logical
                        ordering of strings.
#009# What is a logical ordering of strings? how does it differ from their
      physical ordering?
                        It normally consists of either a single character
                        or two or more characters collating as a single entity
#010# This seems to mean that two strings can be ordered by one 
      single character?
#011# The "entity" at the beginning of this sentence seems to be of a different
      kind than the "entity" at the end of the sentence.
#012# What is the "not-normal" situation?

concatenation  
                        logical operation which consists in adding an element 
                        at the end of a string to consider the result as a new
                        string, longer than the first one.

#013# What is a "logical" operation? Does it involve the logical connectives
      'and', 'or', 'not'?
#014# In what sense is an "operation" different from a "process"?
#015# Concatenation has here been defined as of type:
        Concatenation : X-string x X -> X-String
      Instantiating X by Char gives a definition different from the earlier one.

equivalence   
                        in a comparison between two character strings,
                        a form of partial equality between the two strings.
                        After decomposition of the two strings in different
                        levels according to the ordering table ...
#016# It is unclear that the ordering table describes a decomposition
#017# The ordering table is called elsewhere in this document: 
      - common template ordering table
      - Common Template order description
      - Common Template table
      - common template
      - International Common Template Table
    .... The typical case ...
#018# It is believed that examples should not be used in a definition clause

field                 for the purposes of this International Standard,
                        a single character string or any other data type
                        which may be ordered alone(?) or in conjunction
                        with other fields of a record, each field of a record
                        being compared to the same field of another record;
#019# Is "a single character string" the same as 
         "a string containing one character" or 
         "a single string containing characters"?
#020# It is unclear how such a string can be ordered "alone"
#021# It is unclear what a "record" is; see later comment
#022# Precisely the "same" field? Perhaps corresponding?
#023# A data type (in SC22 terminology) can not be ordered; values of a data
      type may perhaps be ordered.
                        in case of absolute equality of two equivalent fields,
                        other fields of the records ....
#024# Yet another definition of equivalent? 
#025# What is absolute equality?
#026# It is believed that is not proper to distribute the description
      of the algorithm throughout the document.

first order token 
                        an absolute number used as a comparison element,
                        obtained out of tables for the first level that
                        describes a character; ...
#028# What kind of element is this?
#029# Absolute number; does this have the mathematical meaning of |x| ?
#030# It is unclear to what part of the sentence "that" refers to;
      the number, the element or the level?
#031# Does a level "describe" a character?

fourth order token 
                        an absolute number ....., obtained either out of,
                         or specifying  the position ....;
                        tokens of the fourth order level are always in pairs
                        the first token being a position, the second one 
                        being a weight ...
#032# The first sub-sentence states that  a fourth order token consists 
      of "one" absolute number; the second sub-sentence states that 
      a fourth order token is a pair.
#033# The first sub-sentence states that a fourth order token is an 
      "either-or" the second sub-sentence states that it is a pair.

level   
                        Whenever used ....level .."key level" .."precision
                        level" ... conformance level...
                         normally ...
#034# Why such a difficult terminology? Why not just use precision level
      and conformance level throughout?
#035# What is the abnormal situation?
#036# It is again believed that it is not appropriate to detail the 
      algorithm here.

numeric relative value 
                        the relative .. in its final numeric and processable
                        form
#037# Are there non-final forms?
#038# Are there unprocessable forms?

ordering key  
                        a series of bits, the numerical value of which
                        determines its order;
                        to a character a ..... characters
#040# The second sub-sentence seems unconnected to the first one and is again 
      discussing the algorithm

posthandling  
                        a process in which ... internally ... straightforward
                        comparisons ...
#041# What is a process?
#042# What is meant by internally? Internal to what?
#043# Why are the comparisons done according to this standard "straightforward"?

record   
                        the exhaustive structured set of fields that 
                        form a monolithic block in a file ....
#044# What is exhaustive here?
#045# In mathematics sets are unstructured. What is the structuring criterion?
#046# What is meant by monolithic?
#047# What is a block?
#048# What has a file to do with all this?

reference string ............ a base reference ..
#049# Are there also non-base references?

string   
                        a series of individual elements which form a whole,
                        when they are concatenated ...
#050# It seems that this definition disallows character strings consisting 
      of a single character

transformation  
                        A(a?)n operation performed prior to comparison or
                        ordering ...
#051# What is the difference between comparison or ordering?
      This definition helps to have a more general discussion on the 
      terminology used in this standard.
      There are three verbs that are central to this standard: to order,
      to compare and to collate.
      Looking up the meanings of these verbs in this definition clause and 
      in a dictionary does not bring much light in the question of what the 
      precise definition used here is.
      Looking ahead in the document one finds that the API only allows for 
      comparisons to be done. 
      The mechanism is such that first strings are mapped to unique values
      (isomorphic to integers; what is called an injection in mathematics).
      These values are then compared using the underlying ordering of 
      the set of integers.
      The fact that the strings can then be (re)ordered seems to be outside
      the scope of this standard.
      Collation has not defined here at all. Looking up its meaning in Webster's
      gives again 'to compare' and 'to order', but does not give any insight.

5.1 Prehandling phase ...

This requirement shall be met for conformance levels greater than 1

#052# This requirement -> The requirement specified in this clause ...
#053# Conformance requirements have been indicated by letters!

It is recommended ..
#054# This recommendation conflicts with "shall" in the first sentence.
#055# But, this whole sentence seems misplaced here.

The symbolic table, ...
#056# No symbolic table has been provided in this document
shall be provided in a numeric form 
#057# What kind of numeric form? floating point numbers?
.... each element of the matrix being a numerical token indicating 
one or more relative weights.
#058# Numerical token has not been defined
#059# Relative weight has not been defined
#060# Can "one" token indicate "more than one" weights?
#061# What is the meaning of "to indicate a weight"? As a balance?

#062# Generally speaking, it seems somewhat of an overspecification to require
      that the table be built in a particular(matrix) form (n *m array).
      As long as the outcome of the comparison of two strings conforms to the
      requirements of this standard, the internal form used for data seems
      not significant.

However(,?) the values used shall respect the order specified in the 
symbolic table data.
#063# No symbolic table can be found in this document.

Conformance level C requires that the API shall allow to choose a table
built at a preceding time
#064# What is "a preceding time"? Earlier than prehandling? 

It may be necessary to transform a field of a record 
#065# Into what?
... or to transform unstructured records
#066# What are "unstructured" records? Please note the definition of records 
  in clause 3
... into structured fields 
#067# Given the definitions of record and field in clause 3 this 
      definition is incomprehensible
... before the actual process can begin.
#068# Yet another process?
The implementer is responsible for ensuring ...
#068# The implementer of this standard? How can that be?
This is a global operation
#069# What is meant by global?
#070# So an operation is a process?
that may involve "exploding" records before ordering them
#071# How does one explode an "exhaustive structured set" or 
      a "monolithic block"?
#072# Are these records ordered, or are the strings ordered?
Therefore, the prehandling phase ...
#073# Why a conclusion here?
Thus, prehandling is not part of the comparison operation API.
#074# Why a conclusion here? We already knew that.
The comparison API will not contain any default method related to prehandling.
#075# What is a default method?
#076# Isn't this derivable from the previous sentence?
...for allowing the use of this IS in higher layers of the application?
#077# It seems inappropriate for this standard to state anything about the
      structuring of an application using this standard.

The prehandling phase ... transform the actual coded characters used on input
#078# In the previous section it was said that prehandling operated on records?
....Then the prehandling phase can correspond to the empty process
#079# So a phase is equal to a process?
Ideally, all control characters
#080# Ideally = shall/recommended/optional ?
#081# Elsewhere, control characters have been named control functions
.. in case of absolute homography ...
#082# Homography between ? and ?
#083# Homography means "equal in writing"; what is absolute equal in writing?
... in the common template
#084# No common template can be found in this document

5.2.1 ....
The general interface consists in (of?) three ...
#085# Is there a specific interface too?
#086# Several typos here
#087# It is unclear why these procedures have been numbered
#088# It is unclear how CARABIN can _produce_ a _PRE_fabricated bit string.
#089# It is unclear whether there are bit strings that are 
      processable indirectly.

The implementer may choose appropriate values for the application.
#090# The implementer of this API chooses values for an application 
      he does not know anything about?

#091# General remark: As far as understood, all three 'procedures' are 
      effectively functions (ie they have no side-effect).
      It is unclear why they are called procedures then.

5.2.1.1 .....
table .... If this parameter is not provided, the common template 
will be assumed.
#092# It is unclear how this should be implemented in a language 
      that requires all the parameters being present.

COMPCAR process:
This procedure shall be processed to give results equivalent to the following:
This procedure shall be processed to give results equivalent to the following:
#093# Two times the same sentence
#094# Yet another use of equivalent
#095# Process or procedure?

Submit character strings string1 and string 2 and table 'table' to
procdure CARABIN ...
#096# CARABIN does not have such parameters.
      After having looked up the definitions, it is clear what has been 
      intended, why not describe it precisely?
Execute procedure ....
#097# Perhaps process the procedure?

A minimum interface for conformance level A or B can very well(?) use 
the standard C-language function model of ...
#098# Why "minimum"?
#099# The C-language has no notion of function model

This limited interface ...
#100# Is a limited interface the same as a minimum interface?

COMPBIN process:
.... coded character strings ..
#101# Undefined notion
... octet by octet ...
#102# Unclear what octets have to do here

5.2.1.3.
....to a comparable bit strings
#103# All bit strings are comparable, aren't they?

... not to compile this table 'table' every time this function is called.
#104# It is unclear what compilation model is used here. 
      Is this compilation the the same as the earlier mentioned prehandling?