ISO/IEC JTC1 SC22/WG20 N813

May 11, 2001

 

DATE:                    May  9-11, 2001

 

TIME:                     9:00 a.m. to 5:00 p.m

 

LOCATION:         Saphor    (map)
Fronländer 22
Tübingen / Bühl   72072

                                Tel.: (+49) / (0)7472 / 949 100

 

Web site for documents:    http://wwwold.dkuug.dk/jtc1/sc22/wg20/docs/documents

 

1.     Introduction and announcements by Convenor

Thanks to Marc Küster, Saphor, for the hosting.  Announcement about the social event. 

2.     Introduction of national delegations, liaisons, and cooperation partners

Prof. Kim from Korea is a delegate of the National Body of Korea (O-member of SC22).  Also present are USA, UK, Germany, Norway, and Canada.  See N811 for the list of participants.

3.     Appointment of chairperson, secretary, and drafting committee

Simonsen is the chief drafter.  Arnold will chair and take notes. 

4.     Approval of prior meeting's minutes  [N786]

Approved, no changes

5.     Future Meeting Schedule and Plans

2001-10-1/3, Malvern, USA

2001-10-4/5, Malvern, CLAUI

2002-05-20/22, Tromsø, Norway

October 2002 – possibly Japan

 

AI Winkler to check with Takata the possibility of a meeting in Japan

 

6.     Recognition of new documents and assignment to agenda items

 

 

 

7.     Approval of Agenda  [N810]

Approved as amended

8.     Results from the JTC1 meeting in Tromsø and the ISO/TMB

For information only.

AI Winkler:  check with secretariat:  TMB-8/2001 on late work items – does this have an impact on 15435 ???   Answer: NO, not applied to JTC1 yet.

AI Winkler to check:  TMB-5/2001 – electronic balloting, distribution in paper form ? 

Answer: YES !

TMB-12/2001 – industry participation ?  Trial period for paid seats in the SCs. 

9.     Liaison Reports

9.1     Additions/deletions/changes to liaisons

 

 

9.2     SC22/WG4, COBOL

No report.  Keld reports that the FCD 1989 is out for ballot.  This is a major revision.  The document refers to TR 14652 for case mapping.

Check with Ann if this is correct. 

9.3     SC22/WG5, Fortran

No report.

9.4     SC22/WG14, C

Keld reports, that there is nothing to report on I18N in C at this time.

9.5     SC22/WG15, POSIX

This is a joint ballot in IEEE and JTC1.  Does not mention any WG20 work.

9.6     SC22/WG21, C++

Keld reports that C++ met last week and that there are plans to enhance I18N features.  Library TR project is requested.  Matthew Austein is the chair, Stephen Clamage is the US group chair.  See the Austin group web site for the new C++ draft.

9.7     SC2/WG2

See N826 for Ken’s report.  ISO 10646 part 2 is almost ready, fonts need to be completed.  First amendment to 10646-1:2000 is progressing.  Another 1000 characters are being added. 

DPRK asked for re-ordering of Korean, WG2 answered with the principle of not changing names or the order – 14651 is the way to sort data, not the binary code.  See resolution M40.1, point e in document N825 for WG20’s involvement of the sorting issue (Professor Kim’s ad-hoc group). 

9.8     GUIDE/SHARE Europe

No report.

9.9     SC35

Alain reports:  work on mobile personal assistance user interface. 

2 new work items on CLAUI testing and assessment failed, now pursued as TRs. 

Next meeting in Stockholm, July 2-6, 2001. 

9.10     CEN TC 304

European Localization Requirements.  Was in review stage.  Report by PWC was published, I18N and L10N is important, TC304 should be cancelled, registry for locale information is needed, lots of contradictions. 

Marc’s personal opinion:  lots of the work will be done in workshops instead of in the TC.  The results are workshop agreements which are not just standards.  Other CWAs are possibly not any more successful than TC work.  CEN plenary will be called to discuss the future. 

Workshops are funded by the commission. 

Other working formats are being discussed.  Somewhat better functioning workshop process is expected from this exercise.  All current workshops are closed, with or without agreements. 

EN 1923 is still considered as open, downgraded to ENV.  No known implementation. 

AI Winkler:  make the PWC report a WG20 document. (N841)

 

Ordering:  EN 1317 is published.  It is a profile of 14651. 

 

Technical issues:  

Matching report, N815.  Not much movement, the report is considered a finished work item.

Taxonomy N814:  fair amount of disagreement about this document – work assignment, WG20 is called out often.  Technical comments were provided by Ken.  Discussion about the taxonomy and the viability of the subjects will be in point 14. 

Keld explains the history and the intent of this work.  CEN has not done anything with it so far.  Was out for a ballot with comments from the US (Whistler).  Ballot concluded that there were problems with the current document, new work might be started, also in connection with the PWC study results.  WG20 must be considered, before the new work is published. 

“Responsibility” is the key word – does the taxonomy assign responsibility for a specific technical subject?  If so, this should not happen. 

Ken:  finds the taxonomy misleading, assignment of responsibility is incorrect.  Marc as the German delegate recommends to dis-own all areas where WG20 is quoted.  As CEN liaison he understands that WG20 is involved in some areas for which we provide registration possibilities. 

Baldev recommends to get rid of the right column of document N814.  Put only the working groups program of work into the taxonomy. 

Ken also points out the incorrect characterization of the Unicode Consortium, which is involved in many I18N areas of interest.

Ken critiques that the document is not a taxonomy, but at the best a classification.  Relationships in this taxonomy are incorrectly defined.  Make it coherent.  Ken promises more US comments.  The codes in N814 have no meaning, in a real taxonomy the would have it.

Call it a classification with a more rationally structured table, independent of existing standards activities. 

Some discussion about the way, a taxonomy has to be constructed, and how to avoid incorrect impression, what it means to quote e.g. “grammar” in the list of items. 

Baldev suggests a new way to construct a new document that is based on user requirements independent of platform, standards, and working groups, and the way the individual items are worded.  The current document must be stopped. 

Marc will report the conclusions of WG20 to CEN.

 

9.11     TC37

Language codes report from John Clews.  A new work item in TC37 has been approved to produce a new standard about language and country codes ….  It seems that UK is funding a consultancy report to that subject.  John will dig out the paper and report in more detail. 

Department of Defense (DoD) is very interested in this work also.

Keld:  ISO 12199 has been published.  This is the TC37 ordering standard, identical to the CEN standard, can sort by bold, italic, etc…  Mainly for use in libraries.  Thorgeir is the TC chair for the time being.

9.12     Unicode

Ken reports:  N827 announces Unicode 3.1.  Unicode synchronized to 10646-2.  Datafiles and properties are updated, etc…   Now there are 90000+ characters in Unicode 3.1.  UTF-16 is now needed in software to support these new characters in planes 1 and 2.  The collation report has been updated to cover the repertoire of 3.0.  UTS 10.0 is approved by UTC, it is referenced by ICU.  Ken provides the draft table, which has been approved by UTC. 

N830 is a request from the International Unicode Conference in Hong Kong about C and C++ data types for Unicode to support UTF-16.  The document describes the request.

Keld reports about discussions in C working group about this subject.  Would allow implementations that are conformant to 10646 and Unicode.  Main goal is a portable way to process unambiguously UTF-16 characters.  No immediate action is required. 

Arnold suggests that Keld distribute the document as an early warning to C and C++ so that they can comment before it is a official request. 

AI Keld:  send 830 to C and C++

9.13     W3C

No specific report, Arnold was unable to attend any of the W3C meetings.

10.     Review of prior meetings action items  [SD-5]

Discussed, marked.

11.     ISO/IEC TR 10176

Publication problems – full TR, not an amendment.  This requires some edits in the text before publication.

Do we need a new amendment for the expanded repertoire ??  Proposal for web-table ??

The current comments from ITTF are accepted, the TR should be published as third edition, even if only the table changes. 

AI Winkler:  inform ITTF to publish TR 10176, third edition, with the suggested edits.

We need a generic way of changing and publishing tables without changing the text of the TR.  Ideas ?

Arnold writes a paper to propose to ITTF the possibility to have a table on the web site separate from the standard or TR.  The paper, N838, is reviewed, amended and approved.

AI Winkler:  send N838 to ITTF

AI Winkler:  Request to include a request for amendments to the table in order to match the repertoire of 10646 parts 1 and 2,  in the convenor’s report.

12.     International string ordering  ISO/IEC IS 14651

We do not know, if the first revision has been published. 

AI Alain:  send a notice to Keith Brennan asking for information on the publication.

Done, YES, 2001-02-26

 

12.1     Impact of 10646-1:2000 and 10646-2

 

 

Ken has provided the document N833, the new table which matches the collation in Unicode.  Used in ICU, also in UTS  #10. 

Proposal to go out with this new table and the text of the amendment for PDAM ballot.  Problems with page 2 of N832 which includes copyright statements and a title which at that time is not valid (amendment). 

Discussion about the naming of the amendment – year or amendment number or both ?  Since 14652 and 10176 have the same problem, we should propose a numbering scheme that makes the synchronization with the repertoire of 10646 obvious. 

We decide to not ask for ITTF, we will suggest that the name of the amendment will contain the year of publication.  We anticipate 2002 as publication date for this amendment. 

 

N834:  These are discussion items that Mark Davis is asking.  Ken presents them.

ICU group made suggestions for discussions – some have implications for 14651.

Tailoring syntax is not defined, use whatever …

Stability is the most important issue:  stability of keys is important in data bases and indexes.  Subsequent versions could create weights that differ from weights from earlier versions.  ICU has gaped absolute values, POSIX might not.  14651 is not defined to do such automatically.  We need to consider gapping the table with input from the roadmap.  Work on base table, gap for tailoring. 

Freeze on a specific point (e.g. part 2 and part 1:2000 with amd. 1) and add the new scripts to the end.  For historic scripts, ordering has no great importance, can go to the end. 

Key values generated by applications can remain stable when characters/scripts are added for backward compatibility.  Baldev helps in the formulation of this resolution. 

Questionable ordering:  ICU tests showed that tailoring can become excessive – NBs should look at the table to fix order for optimization…

Change in æ :  keep as is so that the European ordering rules are not made “non-synchronized”.  EOR have been implemented, changes in base table would be a bad thing. 

Same for Russian, no impact on 14651.

Field separator:  for concatenation of names when sorting names from data bases it would be possible to get a nice list together.  There are advantages to any way of handling spaces, non-break spaces, etc…  This is a well thought out proposal.  Alain suggests that spaces are removed, while NBS remain, but this does not invalidate the proposal.  This proposal uses a control code that is used as intended.  The lowest level for the unit separator  (1F) allows that.

Agreement:  requests from the US can be expected in National ballot comments.  Other requests from other bodies might come also. 

Prof. Kim:

14651 might be hard to understand – he gives exact examples.  Alain and others explain.  Kim has collected many questions which needs to be answered.  See below.

Relationship of 14651 and 14652 – FDCC set need keyword extensions in 14652 for extended internationalization POSIX. 

Common template table – annex A, base for all tailoring;  collation table – any table that is structured like the CTT. 

Reference name of the table – filename.txt

Symbols:  s….  symbols that carry primary weights; d….  symbols that are diacritics and carry secondary weights.  Mostly auto-generated, using the code point.

Collating element:  symbols in the table for one or more characters in the text.  Selfdefined symbols as conventions U+xxxx. 

In POSIX, each weight finally gets a number.

In Korean, for the Hanguls:  weight to every Jamo, weighting element is the total of all individual ones.

More questions on Friday, all answered.

 

12.2     Runic script

Runes were added after 14651 cut-off.  Order of the Runes in N833 are according to the preference of the ISO Runes project (Sweden).  Other people, such as Everson and Ken, disagree with the ISO project and prefer the current usage on the web.  Reason: academic work is done in transliterations and the order is for the transliterated characters.  Everson’s proposal is very close to the binary order in 10646 (Fuþark) for all extensions in various countries.  Transliterated order would have to be a tailoring.  Current draft table shows the ISO Runes order. 

Discussion about the merits of either ordering.  Decision that the order stays as in the table which is the Fuþark order. 

Resolution:  request combined registration and PDAM ballot for amendment 1

AI Winkler:  send 14651, amd #1 to SC22 for PDAM ballot, add to convenor’s report.

 

13.     Cultural convention specifications  ISO/IEC PDTR 14652

13.1     Progression of DTR 14652 – just for information

Vote ends on June 26, 2001.  NB comments must be accommodated before the publication, once the TR is approved. 

14.     Registration of cultural elements  ISO/IEC 15897

Discussion about the taxonomy:

Keld introduces the new draft N803, the paper contains a list of changes from EN 12005 and IS 15897:1999 in Annex H.  All normative references to 14652 were revised. 

AI Winkler:  send the latest version of ISO 2375 to Keld to lift the text from there into 15897.

Discussion of the draft:

Clews:  shorten annexes, when they seem to be duplications.  Keld explains that they can be examples.  Perhaps one example is sufficient. 

Soor:  will there be processing on the registrations (introduction) ?  The registered cultural elements will be free of charge.  Charmap and repertoiremap are not cultural conventions. 

Ken:  first line of all examples must specify the file format.

Definition of Locale and FDCC set need to be aligned.  Be consistent – work with POSIX locale always.  Clarify registration request process – sponsoring authority.  Details on rules for the proposal – format, language, etc…  Narrative registrations can be submitted on paper to be scanned.  Search only on machine readable form.  What is “ordinary” text ? 

Format:  for parsing, the submission should be in text format, for narrative submissions the same tools as for JTC1 submissions .

Correct references of annexes (e.g. in note 2 on page 8.)

6.9: why is canonical called for here ?  Reference character identifier short form.  Do this consistently throughout the document.

Progression:

May 20	Winkler	Send ISO 2375
End of May	Simonsen	Final draft to Winkler
End of June	Editing group	Review, comments
First or second week of July	Winkler	Send for registration and CD ballot.

 

15.     Internationalization API standard  ISO/IEC 15435

15.1     Project 15435

N805 was provided on May 11, 2001 – no new draft of the standard is available. 

Keld explains the document N805.  He shows the potential use of the standard on various operating systems.  Keld expects good success in up to 10% of the end user systems. 

The document N805 is not a market requirement document, showing where people are looking for something they want to have.  It is much more a document that shows a rosy picture of unconfirmed opportunities.  Mac and IBM people are not asking for it, Microsoft is not interested, UNIX/LINUX seem to have requirements, but not necessarily for this APIs. 

Baldev: IAX has a decent I18N solution, they don’t need any more.  IBM 390 systems have no interest, they might go for Java.  Baldev asserts that the chances of the APIs are exclusively in the POSIX extension world, using C. 

Marc:  the only requirement he ever saw, was COBOL, and there the new standard is being balloted now – this means that the standard will not be changed for at least 5 years. 

There is no liaison statement from C nor from C++, also no resolution that requests such work as the API standard would support.  Keld will try to make the relevant sections of the minutes available.  LINUX has not adopted the proposed API standard. 

Discussion about the possibilities that the API standard is not required – Sun, IBM, HP are not interested.  NCR is ambivalent, LINUX I18N is not in favor, nor is Siemens. 

Arnold suggests, to give the current draft to LINUX or C or C++ and not do anything in WG20.  Baldev supports this concept – he would need a requirement statement for continuing with the API standard 15435. 

Keld wants to go forward and submit the document for registration anyway, the group is against this progression. 

Marc recommends to allow a few months (until just before September’s SC22 meeting) for a strong market requirement to show up in writing.  Otherwise no action.

16.     ISO/IEC 10646 Issues

Ken explains the magnitude of part 2.

17.     Other business

17.1     Convenor’s report 2001

What requests do we have to SC22 ?

TR 10176 web table (see N838). 

Concurrent registration and PDAM ballot for next amendment of 14651.

17.2     Language codes

John Clews - for information.  Document N835 was distributed.

TC37 wants to maintain a data base freely available on the web.  (~500)

Additions for more languages (~ 8000)

Coding mechanism for variations – standard or TR. 

Each of above 3 is explained in more detail.  UK will fund consultants to create the DB and additions. 

IANA registry: RFC 1766 is now RFC 3766.  Use 2 letter code where available, 3 letter codes where necessary from ISO 639-1 and 639-2. 

In ISO/IEC 15897 we have the similar rule about 2 or 3 letter codes. 

Discussion of current use of codes (ISO, SIL, IANA) in practical applications. 

Baldev asks practical questions about registration of new codes, examples, use etc…

Ken:  solution would be the definition of a namespace for language codes such as SIL codes. 

After some discussion, Arnold says that this is SEP.  He thanks for the information, L2 will comment.  (copy Gerhard Budin, Austria).

17.3     Resolutions from IIT-RG in Copenhagen

Keld provides the paper.  The rapporteur group from JTC1 asks for input. 

Arnold asks NBs to contribute. 

Keld suggests discussion on teleconferences to speed up resolutions of single issues. 

Frank Farance from the USA is chairing this group, not as a US delegate.

 

18.     Review of Priorities and Target Dates

Are defined in the progression of the work items.

19.     Review of Actions Items from this meeting

See SD-5 on the web.

20.     Approval of Resolutions

Resolutions are read, amended, and finally approved.  Special thanks to Marc Küster for his outstanding hosting.

21.     Adjournment

Meeting is adjourned.