Subject: SC22 N2911 - Vote Summary of FCD 14651 - Method for Comparing Character Strings and Description of a Common Tailorable Ordering Template (fwd)

From: William Rinehuls <[email-masked]>
Date: Mon, 19 Apr 1999 16:36:13 -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
N2911

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

DATE ASSIGNED:
1999-04-16

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 make a
recommendation on the further processing of the FCD.

Please note that the comments accompanying the vote from the Sweden Member
Body were made available only in pdf format.  The nature of pdf files
precludes their being integrated into this summary and these comments are
being distributed as document SC22 N2912.

ACTION IDENTIFIER: FYI

DUE DATE:
N/A

DISTRIBUTION:
Text

CROSS REFERENCE:
SC22 N2844, N2912

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 N2844
Circulated by:               JTC 1/SC22
Circulation Date:            1998-11-30
Closing Date:                1999-04-08

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

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

"P" Members supporting approval
      without comment                     6

"P" Members supporting approval
      with comment                        4

"P" Members not supporting approval       6

"P" Members abstaining                    2

"P" Members not voting                    4

"O" Members supporting approval
       without comment                    1

"O" 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 comment accompanying the abstention vote from Australia was:  "No
expertise in this area."

The comments accompanying the affirmative vote from Austria, Canada,
France and the United Kingdom are attached along with the comments
accompanying the negative vote from Denmark, Germany, Ireland, Japan, the
Netherlands and the United States of America.

The comments accompanying the negative vote from Sweden were provided only
in pdf format and are being distributed as document SC22 N2912.

_____ end of overall summary; beginning of detail summary ______________

                 ISO/IEC JTC1/SC22  LETTER BALLOT SUMMARY

PROJECT NO: JTC 1.22.30.02.02

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

Reference Document No:  N2844           Ballot Document No:  N2844
Circulation Date:       1998-11-30      Closing Date:  1999-04-08
                                                              
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)      ( )       ( )       (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 detailed summary; beginning of Austria comments ___________

From:  Martin Schoenhacker <[email-masked]>
Subject:  Austrian vote on N2844

The Austrian vote on

   SC22 Letter Ballot N2844 - Approval for FCD 14651 - Method for
   Comparing Character Strings and Description of a Common Tailorable
   Ordering Template

is YES with an editorial comment:

   On page 35, paragraph 4, line 1, word 2 should read:  "public-domain"
   rather than "plublic-domain".

_____ end of Austria comments; beginning of Canada comments ____________

From:  Doug, Langlotz <[email-masked]>
Subject:  REVISED Canadian reponse 22N2844

Canada SUPPORTS the document with the attached comments:

"Canada wants to make sure that relative weights in the template respect
those of special characters as in Canadian standard CAN/CSA
Z243.4.1.-1999.  Furthermore Canada insists that this International
standard shall allow to declare a minimal Canadian delta without having to
do prehandling (the delta shall be specifiable simply by declaring a
modification of the table), in order to fit with Canadian industry
practice.  Canada will not accept any change that would jeopardize that
objective."

_____ end of Canada comments; beginning of Denmark comments _________

From: Pia Junker Hviid <[email-masked]>

Subject: Danish vote on JTC1/SC22, N 2844

We can inform you that Denmark votes NO on ISO/IEC FCD 14651, N 2844
with the following comments:

1. The main table should be included in the standard ad verbatim.

2. The weights on the second level should include a <BLANK>
weight for all letters with accents, to ensure as equal treatment
as possible of fully composed characters and split-up characters,
in non-normalized text. This addresses 6.1.1 note 1, which should
be removed.

3. In clause 5, The notation "UXXXXXXXX" should also be allowed.

4. In the main table, the control characters of ISO/IEC 6429 C0
and C1 should be included, and ISO 6429 be added to clause
3, references.

5. in 6.2.2.2 description of level 1, please change "basic letter"
to "first-level letter". any basic letters of for example
the Latin script are not sorted uniquely at level 1, eg: Æ, Ø, Å.
Also for the description of 2nd level: it is culturally dependent
what "diacritics" means, and the term should be avoided in an
international standard. For example "Ø" and "Å" are not  diacritic
letter, but base letters, in some languages.  There is no diacritic
in these letters.

5. in 6.3.1 - the BNF should be terminated with a semicolon.

6. in 6.3.1 rule 13 should also allow for a '<U' eight_digit_hex '>'

7. 6.3.1 and 6.3.2 should be explained in terms of a narrative
description as the 14652 LC_COLLATE category specification.

8. 6.3.1 should be aligned with the 14652 BNF for LC_COLLATE,
also in terms of terminology used..

9. There should be tokens "LC_COLLATE" and "END LC_COLLATE" to
surround the whole specification in 6.3.1.

10. 6.3.1 rule 8: space should consist of one or more spaces or tabs.

11. 6.3.1 rule 28: The name should be "section-symbol".

12. in 6.4 references to 6.3.1 terms should be in italic.

13. The examples with reorder-after should use "-" instead
of "_" in the keywords.

14. 6.5 - The name should be following ISO/IEC 15897 naming.

15. in Annex B.1  the line 5 should have <> around TABLE, as in
         order_start <TABLE>;....

16. Annex B.2 : change "assumption that character mnemonics
are resolved into UCS identifiers" to "mnemonic identifiers for UCS
defined in ISO/IEC 14652"

17. Key generation on-the-fly should be described, eg as a note
at the end of 6.1.2, saying that comparison with keys generated
on-the-fly character for character is an equivalent way of
implementing the key generation,and may eliminate elaborate
key generation when a difference is to be found in the first few
characters.

18. Position should be specifiable on all levels, as it is legacy from 
POSIX.

19. Toggles "ifdef" etc as in 14652 should be reintroduced.

20. The conformance clause needs to be reformulated. It should not
be possible to claim conformance to 14651 if full tailoring
is not available with the application. That would mean that
eg. Danish specifications cannot be accomodated by the application
and that defeats the main purpose of this standard. The conformance
clause does not read as English. Ith should also be possible
for a specification to claim conformance - possibly in the
way of 6.4 tailoring.

21. The Danish test data in annex B should be replaced with the 
following:
A/S
ANDRE
ANDRÉ
ANDREAS
AS
CA
ÇA
CB
ÇC
DA
ÐA
DB
ÐC
DSB
D.S.B.
DSC
EKSTRA-ARBEJDE
EKSTRABUD
EKSTRAARBEJDE
HØST
HAAG
HÅNDBOG
HAANDVÆRKSBANKEN
Karl
karl
NIELS JØRGEN
NIELS-JØRGEN
NIELSEN
RÉE, A
REE, B
RÉE, L
REE, V
SCHYTT, B
SCHYTT, H
SCHÜTT, H
SCHYTT, L
SCHÜTT, M
ß
SS
SSA
STORE VILDMOSE
STOREKÆR
STORM PETERSEN
STORMLY
THORVALD
THORVARDUR
ÞORVARÐUR
THYGESEN
VESTERGÅRD, A
VESTERGAARD, A
VESTERGÅRD, B
ÆBLE
ÄBLE
ØBERG
OBERG

______ end of Denmark comments; beginning of France comments __________

TITLE: French ballot comments on ISO/IEC FCD 14651 - Method for Comparing
Character Strings and Description of a Common Tailorable Ordering Template

SOURCE: AFNOR

DATE: 1999-04-08

France votes YES on FCD 14651, with the following comment:

  Insufficient effort has been done to define an acceptable ordering for
some lesser-used scripts.
  
  A lot of scripts are actually ordered based just on Unicode code values.
When WG20 can find some existing practice of a culturally accepted
ordering not conflicting with another one, these practices should be
included in FCD 14651 default template ordering.
 
  We suggest that experts of those scripts should be invited to define a 
correct default ordering.
    
  For example, this is the case for Tamil (like most other indic scripts)
and Thai scripts, where evidence of existing practice has been demonstrated
and no evidence of other equally valid practice has been found.

  However, considering these issues are more of a concern for national
bodies where those scripts are in widespread use, and even if there is a
Tamil community in the French territory Reunion Island, 
we suggest that this work should be done, perhaps in a future amendment
to this forthcoming standard.

  As the same problem exists with any new codepoints added in the UCS, we
also suggest that we should contact ISO/IEC JTC1/SC2/WG2 to ensure the 
existing procedures to register new characters are adjusted to include 
the needed informations to update the forthcoming collation standard.  

_____ end of France comments; beginning of Germany comments _________

The German member body vote is  "No" with comments.

If the technical comments are resolved satisfactorily, the German "no"
vote will be changed to a "Yes" unless other significant changes be made
to the standard in an unsatisfactory way.

Introduction

General
Germany wishes to thank the editor for many fundamental improvements of
this draft over the previous FCD. They greatly increase the usefulness of
the future standard and render void many essential German concerns.

German comments touch upon two principal points:

Technical comments on the body of the draft and on Annexes_B-E;
Comments on the normative Common Template Table (Annex_A).

Germany does not comment on matters of English style as it is expected
that this will be improved by native English speakers. Lack of explicit
comments on this should not be taken as endorsement of a style that is, as
yet, not always a paragon of clarity. There are many paragraphs where
"loose ends" are noticable, caused probably by numerous cuts and
reworkings over time. Furthermore, Germany does not comment on purely
typographic deviations from the ISO drafting rules (e._g. semicolons 
ought to be used to terminate items of unordered lists). It is confident
that these points will be addressed by the editor at a later stage.

Comments on the body of the draft

Introduction, 2nd paragraph
This paragraph should best be removed altogether, or at least
reformulated in such a way that it does not imply any more that the syntax
of the Common Template Table (hereafter CTT) is in any way normative. The
current formulation of the whole paragraph is unfortunate in this
respect. The draft does not -- and must not -- mandate that conformant
applications can either directly exchange ordering specifications or even
use the CTT in the syntax used in Annex_A.

To stress this point, it is advisable to add another annex with the
specification of another possible syntax. The XML-conformant Swedish
suggestion can serve as a useful starting point.

Introduction, 4th paragraph
Remove 2nd sentence.

Scope: 1st dash
Remove text in brackets ["(independently of coding)"]. Change the
formulation in the remainder of that paragraph to stress that mappings
from ISO/IEC_10646 to any other coding scheme are also permissible.

Scope: 2nd dash
Remove phrase "using a variant of the Backus-Naur Form (BNF)" as the
reference format as such does not use the BNF. It is simply
<em>defined</em> using the BNF syntax.

Scope: Note
Remove note.

Scope: Additions
Add an entry under the heading "This International Standard does#/+not#/-
mandate" to stress that no preparatory procedures are prescribed, but is
normally necessary. Give a reference to Annex_C.

Definitions: 4.9
The term <em>depth</em> does not elucidate the problem but rather
explains an X with an Y. Either define the term or chose a different
formulation.

Definitions: 4.10
The <em>reference comparison method</em> should be defined or explained
in more detail before.

Definitions: 4.11</CommentOn>
In the context of this draft the "set of strings" can always be
understood as having one and only one member (no preparatory procedures
are part of the standard itself). Therefore change the formulation
accordingly.

Definitions: 4.11 (suggestion)
Replace the word <em>order</em> by <em>sequence</em> and reformulate
the phrase accordingly. 

Symbols and abbreviations
Simplify the matter of code-dependence on ISO/IEC_10646. Any application
is conformant that is able to achieve identical results as those of
section_6, but not necessarily in the same way. A mapping between some
encoding system and the UCS and back can be seen as a special case of the
preparation of character strings (cf._6.1.1) and of the presentation of
the resulting sequence after ordering. Therefore, without loss of
generality, a character can be seen as being part of the UCS. In
consequence, the 2nd paragraph except the last sentence should be removed
and the 3rd paragraph can be reformulated accordingly, i._e. it can refer
to the private-zone UCS coding without further preconditions.

Requirements: 6.1.1</CommentOn>
Clarify 1st sentence of the 2nd paragraph. Recommendation: <recom>At
minimum, the preparation shall guarantee that either only precomposed
characters or only combining sequences, which in the context of the
conformant application are deemed equivalent, are presented to the
comparison method ...</recom>

Requirements: 6.2.2.1
This section is not explained in necessary detail and clarity. Concepts
like <em>stacks</em> are suddenly implied ("stacking of the token will be
done"), push and pop operations appear. None of these operations have been
referred to before nor are they explicitely used thereafter.

Technically, the algorithm which the editor obviously has in mind, is, of
course, correct. It should, however, be elaborated in more detail. The
reader which the editor should have in mind here is the programmer who
knows basic devices, but has never worked on ordering.

Typographically, it is difficult to understand why the three paragraphs
in question are printed with identation.

Requirements: 6.2.2.2
The part from  <em>Generally</em>  to the end should be handled as a note
or alternatively as a section (6.2.3) of its own.

Level_3: The topic of #/+variant character shapes#/- ("modified letters")
must be dealt with on level_2 to ensure maximal compatibility with
pan-European requirements. It has no conceptual likeness to "case" and is
not normally used on level_3 (cf._also the tayloring of Informative
Annex_B.1).

Requirements: 6.3.2
Make all text of the explanatory [I.e....]-statements into notes to
stress their informative character or consider other means to achieve that
end. Such a solution might be to add an informative annex that explains
these and other points which concern the syntax of the CTT.

Requirements: 6.3 and WF1
<tt>hex^_symbol</tt>'s are not defined.

Requirements: 6.3.3, items I4 to I6
 The terms <em>normal form</em>, <em>evaluated [weight table]</em> and
<em>collation-element-weighted</em> are implicitly defined here, but are
used nowhere else. Either the definitions are considered to be of
sufficient importance to be included in the "Definitions"-section proper
or they should be removed altogether. In part, they can also be
incorporated in the specifications themselves, as they explain some
requirements more concicely then the corresponding specification itself.

Requirements: 6.4
Remove 2nd sentence of 1st paragraph.

Annex_B.2
Align the presentation of the delta with that of Annex_B.1 (as it stands
the presentation is not conformant to 6.4) and remove all references to
the mnemonics which are altogether irrelevant in this context.

Annex_C (general)
Add a remark on the importance of higher level protocols (e._g. markup
system SGML) for correct evaluation of numerals and other prehandling
objects (e._g. units -- keys -- in a phone book). <em>Context</em> rarely
suffices to achieve anything like #/+total certainty#/-.  Many of the
tasks are quite trivial if we assume an internal tagging like
^<TemperatureInC^>-9^</TemperatureInC^> (cf._C.2.4), but bordering on the
impossible to solve reliably without them (In C.2.4 the word
<em>Temperature:</em> can be regarded as an implicit tag, but most texts
are not nearly that schematic as the examples in this annex assume).

It is to be considered if Annex_C really needs to be quite as detailed
and extensive as it currently is.

Annex_C.1, 1st dash (minor)
Why are the names of the strings in capitals?

Annex_C.1, 2nd dash (minor)
The example text is somewhat obscure (e._g. the remark "according to
noble origin or not" presupposes knowledge that this is of importance when
ordering).

Annex_C.2
The text needs to be clarified to some extend (e._g. what are "Run-
together numerals"?).

Annex_C.2.2
A cautionary note should be added to stress that these preparatory steps
have in some cases (e._g. ordering of telephone numbers in phone books)
undesirable consequences and should then be avoided.

Annex C.2.3, 3rd paragraph
The 2nd sentence ought to be modified. "total certainty" can rarely be
achieved even with information on the context.

Annex_D, item V.2
Change the formulation of the last sentence of the 1st paragraph. German
dictionaries usually employ the German norm DIN_5007. Some dictionaries
explicitely refer to this norm, others simply use it without further
clarification, still others explain their ordering principles in some
detail.

Annex_D, item V.3
Remove phrase <em>for the first time</em> in the fourth paragraph.

Anenx_D, item VII
Remove this item.

Comments on Annex_A: Common Template Table</H1>

General: Names of internal symbols
Either reduce all names to a maximum of five letters for consistency or
  (preferably) give less cryptic names to all of them (e._g.
<tt>^<MACRON^></tt>   instead of   <tt>^<MACRO^></tt>   and
<tt>^<DOUBLE^_TILDE^></tt>   instead of <tt>^<D0360^></tt>).   Names
should best be derived from their description in the UCS.

Variant letter shapes
As mentioned above, variant letter shapes must be distinguished on
level_2 instead of level_3. Letters such as <tt>F WITH HOOK</tt>
(<tt>^<U0192^></tt>)   should best be treated as second level
letters. Ideally, only a-z and thorn should be treated as first level
letters, though Germany sees this last statement as a strong suggestion
for discussion.

Relative order of scripts (point of discussion)
It is seriously to be considered if the relative order of scripts should
not follow a general East-to-West scheme as proposed by the last UK
comments.  This could easily be achieved by "internal tailoring"
the CTT as already done for the special characters of
CAN/CSA_Z243.4.1-1998.  Germany sees this, however, only as a strong
suggestion for an internal discussion in WG20.

Script: Greek
Maximum compatibility with the specifications of ELOT as presented in
WG20/NXXXX is to be sought.  To achieve this the breathing marks Psili and
Dasia should precede the other diacritics.  This is also in line with
usual Greek  (cf. the study CEN/TC304/Nyyy. <tt>COMBINING COMMA
ABOVE</tt> and >tt>COMBINING REVERSED COMMA ABOVE</tt> (with which Psili
and Dasia are -- unwisely -- unified in the UCS) are diacritics which
appear infrequently in languages other than Greek, whereas in Greek they
are very frequent indeed.  Cf._also the approach of the E.

Script: Cyrillic
The order for Cyrillic is not in line with pan-Cyrillic requirements and
contains numerous errors.  The sequence must be brought in line with the
specifications from GOST as reflected in the current edition of the
European Ordering Rules (cf._EOR).  Detailed documentation both from GOST
itself and from other sources will be made available to WG20 before the
May meeting.

Script: Georgian
The ordering of Georgian should be coordinated with the results of
ongoing discussion with experts in the field both from Georgia itself and
in academic organizations.

_____ end of Germany comments; beginning of Ireland comments _______

Irish comments on FCD ISO 14651
Reference: SC22 N2844
Closes: 1999-04-08
Date: 1999-04-08

Although Ireland voted positively on the draft on 1998-01-26, we now
wish, because of subsequent review of the document, to reverse our
position. Ireland votes No on the FCD draft.

Many of our our objections are editorial in nature, and we believe that
our No vote can be turned back to Yes easily if the following points are
addressed appropriately by SC22/WG20:

1	The English text must be revised so that it is in all cases
        unambiguous and grammatically correct.
2	Informative text in the Common Template must be revised so that
        the implication is not made that French backwards-ordering of
        accents is not a special case.
3	The assertion that small letters ordered before capital letters
        is the normal practice for the English language is not made and
        is removed from informative annex D.
4	The Canadian and Danish example benchmarks must provide enough
        examples to interpret the specifications from which they are
        derived.
5	The Common Template should contain orderings for all Amendments
        to 10646 up to Amendment 31, not up to Amendment 7. Ogham,
        Cherokee, and Runic are already in order (except for the Ogham and
        Runic punctuation); Canadian Syllabics will require some work 
        to get it right. 

1. We have remarked on earlier drafts of this International Standard that
the use of the English language is in many cases either ambiguous or
grammatically incorrect. We had offered to prepare a corrected version,
but because text was not provided to us in time before the last meeting
WG20, we were forced to withdraw our offer of making the corrections. We
offer now again to provide a new version with document revision
annotations. We feel strongly about this because in reviewing the draft,
we were often forced to stop and read aloud certain passages in order to
decipher the intended meaning. Examples of grammatically incorrect or
ambiguous sentences:

1	It is demonstrated that by tailoring the Common Template Table to
        add extra token values at level 2 for all precomposed characters
        affected by a diacritics diacritic, it is possible to accomplish
        identical results for combining sequences without requiring that 
        preparation.
2	The scanning properties for the level i being processed needs to
        be carefully monitored. When there is a change in scanning
        direction at level i (this implies implying that the character
        being processed comes from a block that which is different from
        the preceding character processed and which has different
        scanning properties) and the new direction is backward, stacking
        of the token will be done at the position where the change of
        direction has occurred.
3	If the order_start_entry does not uses use the position value at
        level m of a block (the position value is explicitly used in the
        template for the only block defined) then the formation of subkey
        level m is done in exactly the same way as the above-defined
        formation.
4	WF7. No two section_definition_entryOs instances of
        section_definition_entry in a tailored_table may contain the same
        values in their section_identifierOs instances of
        section_identifier. [I.e. That is, multiple definition of
        sectionOs is prohibited; section_identifierOs instances of
        section_identifier must be unique.]
5	[I.e., That is, if one takes two strings, builds keys for each
        based on table 1 and compares them, one should always get the same
        results as when one builds keys for them based on table 2 and
        compare compares them.]
6	In cases where the applications an application has provision to
        allow the end-user to tailor the table himself or herself, any
        statement of conformance shall indicate which ones of the 4
        elements of the previous list are tailorable and which ones are
        not tailorable.
7	Whenever the Common Template Table is refered referred externally
        as a starting point in a given context, either applicative or
        contractual [WHATDOESTHISMEAN???], it shall be referenced using
        the name ISO14651_1999_TABLE1.
8	For very big large, or very tiny small, values, one often uses
        formats like 2.5*107 (to just pick one possible way of writing
        these for the purposes of the examples here).
9	But the Common Template Table has digits as specifies digits to
        be level 1 significant.
10	Such processing is beyond the scope of this International
        Standard, though however.
11	A plublic-domain public-domain reduction technique is described
        in details detail (with ample numerous examples) in Technique de
        rŽduction - Tris informatiques ˆ quatre clŽs, Alain LaBontŽ,
        Minist�re des Communications du QuŽbec, June 1989 1989-06 (ISBN
        2-550-19965-0).
12	To illustrate this (without discussing context analysis which is
        not necessary in what follows), examples of dictionary sequences
        are given here for two languages which whose native order is not
        in the Common Template table:

2. The Common Template states:

% To tailor for French accent handling, or not to make French
% a special case add an order_start statement
% and order_end for Latin in the Latin section, as follows:

% order_start Latin;forward;backward;forward;forward,position

In Ireland we consider French to be a special case, which in fact yields
incorrect sorting for our first official language, and we disagree with
the implication here, namely, that Onot making French a special caseO
does no harm. French is a special case of the default template, just as
Danish and Swedish are. The Common Template must read:

% To tailor for French accent handling, add an
% order_start statement and order_end for Latin
% in the Latin section, as follows:

% order_start Latin;forward;backward;forward;forward,position

3. Annex D states:

3. The third decomposition breaks ties for quasi-homographs different
only because upper-case and lower-case characters are used. This time,
the tradition is well established in English and German dictionaries,
where lower case always precedes upper case in homographs, while the
tradition is not well established in French dictionaries, which generally
use only accented capital letters for common word entries. In known
French dictionaries where upper and lower case letters are mixed, the
capitals generally come first, but this is not an established and stated
rule, because there are numerous exceptions.

This is, as we have said many times to SC22/WG20, incorrect. Lower case
does not precede upper case in English. The concise Oxford dictionary of
current English, cited in the JTC1 and CEN directives as a standard for
the English language, consistently gives, in its 8th edition (1990) and
its 9th edition (1998) the following:

August (month)	May (month)
august (venerable)	may (be able)
March (month)	Polish (of Poland)
march (tread)	polish (shine)
Mass (ritual)
mass (heap)

So for a Common Template it is advisable to use English and German
traditions, if one wants to group the largest possible number of
languages together.

This rationale is therefore unacceptable, as it is untrue. The reason the
Common Template has smalls before capitals (which we do not prefer) is
because that is what is specified in the Unicode template. This text must
be revised.

Let's note here by the way that in Denmark, upper case comes before lower
case, a different but well established rule. This is a second fact
calling for adaptability in the model used in this standard.

This same rule is used for the English language.

Example: to have the following order: "august", "August", numbers could
be assigned indicating respectively "llllll", "ulllll", where "l" means
lower case and "u" upper case.

This example is not sufficient. The actual syntax for ordering smalls
before caps which appears in the Common Template should be repeated here,
along with the actual syntax for ordering caps before smalls.

4. The Canadian delta specifies treatment of THORN and ETH but the
benchmark does not contain examples containing these characters. Please
add: ªorsmsrk, Thorvardur, ªorvarñur, medal, meñal. The Danish benchmark
examples of REE and RŸE are not sufficient to demonstrate E vs. Ÿ. Please
add more examples as well as examples of such as Ree and RŽe.

5. The draft is a bit overloaded with references to English, French, and
German. A few more examples from other languages would be preferred.

______ end of Ireland comments; beginning of Japan comments __________