L2/99-315

L2 comments on JTC1 documents:

October 18, 1999

 

 

 

JTC 1 N 5889 - Request for Category C Liaison between SC 22/WG 20 and the

World Wide Web Consortium (W3C)

http://www.unicode.org/unicode/members/L2/99289-j1n5889.pdf

 

L2 comment: The US NB strongly supports this request

 

 

JTC 1 N 5893 - SC 2/WG 2 Charter - In Support of the SC 2 Business Plan

http://www.unicode.org/unicode/members/L2/99290-j1n5893.pdf

 

 

L2 comment: The US NB agrees with the business plan in JTC1 N5893

 

 

JTC 1 N 5894 - Contribution on Initiating Formal Processing of Amendments to

ISO/IEC 10646 (Response to JTC 1 N 5826)

http://www.unicode.org/unicode/members/L2/99291-j1n5894.pdf

 

L2 comment: The US NB strongly supports this expert contribution.

 

 

JTC 1 N 5898 - Comment from the Netherlands on JTC 1 N 5684, SC 2 Response

on JTC 1 N 5449 on the Issue of the Functioning of SC 2

http://www.unicode.org/unicode/members/L2/99296-j1n5684.htm

http://www.unicode.org/unicode/members/L2/99292-j1n5898.pdf

 

Suggested L2 comment:

 

The US NB has examined closely the concerns raised by the Netherlands NB in JTC

1 N 5898. That document states irreconcilable differences between SC2 and the

Netherlands NB over issues which arose in the encoding of four Romanian

characters.  The Netherlands NB has been concerned with the stability of the

ISO/IEC 10646standard, the market relevance of characters encoded in ISO/IEC

10646, and the clarity of the SC2/WG2 decision process.

 

The SC2 Secretariat responded in JTC 1 N 5684 to the specific concerns raised by

the Netherlands NB. In the instance of the four new Romanian characters, the new

allocation was strongly sought by the Romanians.

 

WG2 has since taken the action to further strengthen and clarify (in JTC 1 N

5894) the criteria used for allocating new characters. Two new criteria were

added: 1) to require the identification of a representative set of authoritative

organizations and/or individual experts and 2) to require consensus support

among user communities and their intent to use the new characters. We believe

that the enhanced guidelines for allocating characters put forth in JTC 1 N 5894

adequately address the quality concerns.

 

In the process of allocating new characters in ISO/IEC 10646, there will be

disagreements from time to time.  However, if there are clear, fair, and

reasonable procedures which are followed, then the results should be accepted by

all national bodies involved. If one national body loses a vote, they should not

then campaign to undermine all future efforts of the Working Group. If a

national body feels the principles and procedures for allocation are inadequate,

then the principles and procedures should be improved. It is counter-productive

to try to slow or curtail future character allocations and a great disservice to

the users and implementers of ISO/IEC 10646.

 

 

JTC 1 N 5899 - Netherlands Comment on JTC 1 N 5698, as requested in JTC 1 N

5754, on SC 2

http://www.unicode.org/unicode/members/L2/99293-j1n5899.pdf

 

L2 comment:

 

Wide Industry Support:

 

The evidence of wide industry support of Unicode/ISO 10646 is not a matter of a

"few hundred of users"; it is a matter of strategic decisions that have been

made by nearly all of the major software companies of the world to incorporate

it into their product lines. The following products are Unicode/ISO 10646

enabled:

 

  Operating Systems:

 

     Apple MacOS 8.6, MacOS X Server, MacOS X (forthcoming), ATSUI

     Bell Labs Plan 9

     BeOS

     Compaq's Tru64 UNIX, OpenVMS

     IBM AIX, AS/400, OS/2

     Microsoft Windows CE, Windows NT, Windows 2000

     Palm OS

     SCO UnixWare 7.1.0

     Sun Solaris

     Symbian EPOC

 

  Databases and Repositories:

 

     IBM DB2 (UDB, AS/400)

     Justsystem Goro

     Microsoft SQL Server

     NCR Teradata

     Oracle Oracle 8

     Progress Software Application Server, Open Application Server,

       WorkGroup Database Server, Enterprise Database Server

     Sybase Adaptive Server Anywhere, Adaptive Server Enterprise

     Unisys UREP

 

  Programming Languages, IDEs and Libraries:

 

  For IDEs, this means the editor itself is Unicode-enabled

  (fully or partially), not just that the programming language is.

 

     Ada 95

     Alis Batam

     Basis Rosette

     GAWK 3.0.3

     Java

     JavaScript (ECMAScript)

     IBM Classes for Unicode (now open source)

     Microsoft VJ++, Visual Studio 7.0 (forthcoming), Visual Basic

     Perl 5.005 (improved in 5.6)

     Sybase PowerBuilder, Unicode Developer's Kit

     TCL, TK

     IBM APL2

     Many C/C++ compilers

 

  Other Systems or Products:

 

     Alis Tango, Gist-in-time

     AltaVista

     Citec DocZilla

     Chinese Star 3.0

     Ericsson A, R and T series mobile phones

     Justsystem Ichitaro, Ichitaro Lite, Sanshiro, ATOK

     Kermit (forthcoming versions)

     Linux products: yudit, mined98, Qt, GTK+ (forthcoming)

     Lotus Domino, Lotus Notes

     Linux xterm (utf-8), qt, gscript

     Microsoft Internet Explorer, Office 2000

     Netscape Navigator

     Novell Distributed File Services,

       NetWare Directory Services, Storage Services

     Open Market Transact

     Richwin Chinese Language Kit

     SC UniPad

     TRADOS T-Window for PowerPoint

     TwinBridge Partner programs

     Union Way Asian Suite

     Unitype Global Writer 98, Global Office

     UrbanPress 3.0

 

  Fonts and Printing Software:

 

  Most recent commercial fonts have Unicode character-glyph maps,

  although they may or may not support large repertoires.

 

     Bitstream Cyberbit

     Dynalab fonts

     FreeType

     IBM Advance Function Presentation

     Microsoft Arial Unicode MS, Lucida Sans Unicode

     Monotype fonts

     Production First Software fonts

     SIL Encore Font Package 3.0

     TrueType font specification (including OpenType and

       Apple Advanced Typography specifications)

 

  Standards:

 

     Unicode and ISO 10646 are synchronized in character repertoire.

     Unicode is required by the new technologies coming from

       the W3C, IETF, and OMG; including XML, XHTML,

     XSL, LDAP, CORBA 3.0, etc.

     WAP-Forum WML

 

 

Universality:

 

The US NB believes that WG2 is well aware that no character encoding standard

can attain complete universality, because of the existence of undecoded historic

scripts, idiosyncratic or personal use characters, and symbolic systems whose

use as characters is debatable. However, it is clearly

within the scope of 10646 to strive for the goal of universality of encoding for

all useful characters, and WG2 and SC2 have shown considerable attention to the

tasks of organizing and setting priorities for encoding of known scripts and

symbols not yet covered by 10646. Arguing that perfection is unattainable is not

sufficient grounds for abandoning the task completely--especially when there is

a quite clear roadmap provided by WG2 for making further progress in completing

the repertoire of 10646. There are many well-known and important historic and

minority scripts still outstanding: Avestan, Phoenician, and Javanese are some

obvious examples. Clearly these can be encoded, and clearly that would increase

the degree of universality for the coverage in 10646.

 

The claim of the Netherlands national body that "more and more resources will be

required to add lesser and lesser used scripts" is unsupported by any empirical

evidence. More resources (in terms of the volunteer activities of participants

in the standards process, and the cost of their support) is required for the

encoding of complex and controversial scripts. The encoding of Mongolian and of

Myanmar were both rather costly in this respect, but that was the result of

their inherent technical complexity as scripts, and not caused by some metric of

number of users. By contrast, some historic scripts such as Phoenician are

well-understood, small, and non-controversial, and would benefit a significant

scholarly community if encoded. The amount of resources required to complete the

encoding of Phoenician in 10646 is quite likely to be considerably less than

that expended over the last several years arguing about two Latin characters for

Romanian, for example.

 

The Netherlands NB requests figures regarding "the cost involved to SC2 members

by a new amendment to ISO/IEC 10646", as if such a cost could be easily totaled

up. The majority of the costs involved are the hidden costs that result from the

complexity and controversy attendant

to particular amendments. And the costs are not equally shared in any case. The

costs to the Chinese national body, for example, in preparing the Amendment for

the Vertical Extension A to the repertoire of Han characters in 10646 were

orders of magnitude greater than the costs

for the Netherlands national body in reviewing it.

 

The US NB also considers that it is completely at odds with the goal of

linguistic and cultural adaptability to imply that minority scripts of the world

are not worth including in the international universal character encoding, is

If representatives from Berber, Javanese, Hmong, Dai, or Philippine communities

wish to see their native scripts included, how can one particular national body

claim that those communities are too small or not important enough to be worthy

of SC2 consideration as part of the international character encoding standard?

 

The comparison to the development of programming languages is irrelevant to the

consideration of how SC2 should be proceeding with 10646.

 

 

JTC 1 N 5929 - Comments from the National Body of Japan on the Activities of

SC 2 

http://www.unicode.org/unicode/members/L2/99294-j1n5929.htm

 

L2 comment:

 

The US NB considers that the issues raised by the national body of Japan in JTC

1 N 5929 have already been adequately addressed by SC2 in JTC 1 N 5894.

 

Regarding specific recommendations raised by the national body of Japan, L2

notes that:

 

Publication of the roadmap by SC2/WG2 as a TR would not make that document any

more visible to JTC 1. It is already a public document available to any JTC 1

member. The reason why SC2/WG2 has not chosen to make it a TR is because it is a

planning document, subject to revision and correction as more information is

gathered regarding various unencoded scripts. Trying to ballot it and publish it

as a TR would simply remove all flexibility from it as a planning document,

thereby eliminating its usefulness. The national body of Japan is effectively

asking to cast the planning document in concrete, which would result in tying

the hands of the committee, making it unable to

respond to the accumulation of better information. That is a recipe for bad

standards-making, rather than improved standards-making.

 

The national body of Japan continues to argue that any amendment of 10646 should

go through the NP process, rather than proceeding by modifying the PoW as has

been the case in the past for 10646. This has been addressed in detail in JTC 1

N 5894. A clear precedent has been established, with very successful results,

for adding scripts to the universal character encoding by the procedural

mechanism of modifying the PoW for 10646 to ballot these additions as

Amendments. L2 sees no merit in the argumentation provided by the national body

of Japan in N 5929 on this issue. Switching to use of the NP process would

simply tie up WG2 in a longer process, with more paperwork, and would result in

inappropriate technical detail work rising to the wrong level of ISO committee

review.

This can only be considered an attempt to block further progress on completion

of the scope of work for 10646, rather than an attempt to improve the process.

 

The US NB has no basic objection to the suggestions made by the national body of

Japan in Proposal 2. The standardization of historical and minority scripts

should clearly involve the participation of relevant experts and native users of

the scripts where possible. However, the implication that work on 10646 cannot

proceed because all of the national bodies will not be able to keep specialists

for

each new draft proposal is not correct. The responsibility of the national

bodies in reviewing proposals for additions to 10646 is to ensure that the

proposals generally accord to the architectural principles and quality

requirements of the standard -- not that they rush out and hire or otherwise

contact experts on obscure scripts that are beyond their expertise or concern.

The national body of Japan did not object when thousands of additional obscure

Han characters were added to 10646, despite the fact that most of the European

national standards bodies had no experts on their committees who could

realistically review the details of those additions. WG2, quite properly,

invested the technical detail work on those amendments to a subcommittee of

experts (mostly from East Asia, but with other interested and qualified

participants) who did the research and prepared the relevant documents for the

amendments. The national body votes on the amendments then amounted to a vote of

confidence in the ability of WG2 to assemble, control, and review the work of

such panels of experts. This is a workable, proven method for extending the

international standard. And L2 considers it inadvisable to tie the hands of

SC2/WG2 in using such flexible and proven methods for proceeding.

 

The US NB also notes that the claim that "the historical scripts to be

considered for the addition to the current standard will be far larger, if they

are to be complete, than those which are currently listed on the roadmap" is of

doubtful accuracy. The listing of historical scripts in the roadmap reflects

current consensus about scripts among the world's leading experts on writing

systems, and is updated regularly as further experts make their opinions and

expertise available regarding particular scripts.

 

The market relevance of 10646 is easily demonstrable by the wide implementation

of the standard. L2 considers the market relevance of additions to the standard

to be a matter of successive completion

of the universal coverage of the standard. Implementers clearly want a single

character encoding standard that will serve for all textual representation needs

in the information industry. Omission

of characters means that there will be lots of little, custom solutions,

difficult to maintain and costly for interoperation. That is why the information

industry, through the Unicode Consortium, continues to support the allocation of

additional symbols, minority, and historic scripts to the standard. The

incremental cost of supporting their additions inside the universal standard is

much less than having to support them with dozens of small, ad hoc solutions

outside the universal standard.

 

For this reason, the US NB considers Proposal 3 in JTC 1 N 5929 to be of little

merit. ISO/IEC 10646 is a standard of clear and evident market relevance. And

attempting to refine the definition of market relevance and then apply it on a

case by case basis for individual NP's for each proposed addition to 10646

misses the point entirely that the value of 10646 to the information industry

lies in its universality and completeness.

 

 

 

JTC 1 N 5930 - Finnish National Body Contribution to JTC 1 on the Japanese

National Body Concerns on SC 2 Programme of Work

http://www.unicode.org/unicode/members/L2/99295-j1n5930.pdf

 

L2 comment:  The US NB agrees with Finland's position.