Thanks to Tim Greenwood for acting as Secretary at this meeting, and
providing notes to supplement those taken by Steve Greenfield as Scribe.
Please review the Minutes for accuracy, and send any amendments to Steve
Greenfield at unicode-inc@unicode.org.
Please note that corrections to the section on Korean have been made to
reflect the postings that several people made to unicore@unicode.org after
the UTC meeting.
-- Joan
============================================================
Unicode Technical Committee Meeting #62
Friday, September 30, 1994
Toronto, Ontario
Hosted by IBM-Canada
Chair: Joan Aliprand
Vice-Chair: John Jenkins
Secretary: Tim Greenwood
Scribe: Steve Greenfield
Attendees:
Corporate Members:
John McConnell, Apple jmcc@apple.com
Tim Greenwood, Digital greenwood@r2me2.dec.com
Mike Ksar, HP ksar@hpcea.ce.hp.com
Don Carroll, HP don_carroll@hpboi1.desk.hp.com
John Gioia, IBM gioia@vnet.ibm.com
Fred Bealle, IBM fbealle@vnet.ibm.com
Alexis Cheng, IBM alexis@vnet.ibm.com
Hossein Kushki, IBM kushki@vnet.ibm.com
Marty Marchyshyn, IBM martian@vnet.ibm.com
Lisa Moore, IBM lisam@vnet.ibm.com
Uma Umamaheswaran, IBM umavs@torolab6.vnet.ibm.com
Ed Batutis, Lotus ebatutis@lotus.com
Sungi Hong , Microsoft sghong@microsoft.com
Young Lim, Microsoft youngl@microsoft.com
Lloyd Honomichl, Novell lloyd_honomichl@novell.com
Joan Aliprand, RLG br.jma@rlg.stanford.edu
John Jenkins, Taligent john_jenkins@taligent.com
Kelsey Bruso, Unisys bruso@unirsvl.rsvl.unisys.com
Associate Members:
John Bennett, Sybase jrb@sybase.com
Individual Members:
Tex Texin, Progress Software texin@bedford.progress.com
Officers:
Joe Becker, Xerox becker.osbu_north@xerox.com
Liaison:
T.J. Kang, WG2-Korea Liaison
Unicode Office Manager:
Steve Greenfield unicode-inc@unicode.org
Guest:
Dirk Vermeulen, CASEC
============================================================
Document Registration:
UTC62-94-020 Agenda
UTC62-94-021 Action Items from UTC #61
UTC62-94-022 Korean Proposal
UTC62-94-023 Missing Glyph Font
UTC62-94-024 Glenn Adam's Report on IRG-Peking
UTC62-94-025 Text of Draft comments on PDAM
UTC62-94-026 Proposed Draft of Amendment 1 (ISO Doc)
UTC62-94-027 Comment concerning PDAM
UTC62-94-028 Repertoire of Unified Aboriginal Syllabics
UTC62-94-028A Revision provided by John Gioia
ISO-IEC JTC1/SC2/WG2 N884 Multi-Octet Coded Character Set
UTC62-94-029 Draft UTF-16 (PDAM 2)
UTC62-94-030 Draft UTF-8 (PDAM 1)
============================================================
Approval of Minutes for UTC #61:
Joan Aliprand had some typographical corrections. Mike Ksar pointed out
that the dates for the WG2 meeting in October should be "October 10-14".
Motion to approve the Minutes as amended moved by Lloyd Honomichl, seconded
by John Jenkins. Motion approved by consensus.
*** Action Item (Aliprand, Greenfield) ***
Incorporate amendments into the Minutes for UTC #61, and distribute amended
Minutes to "minutes" distribution list, and to anyone present at UTC
meeting #61 who is not on the "minutes" distribution list.
Future UTC and Other Meetings:
UTC #63:
This meeting, originally scheduled for December 1-2, is the annual
Membership Meeting, at which Directors are elected. Apple and Borland are
co-hosts. It was previously decided that the meeting would be held in
Cupertino (at Apple facilities) rather than at Borland's offices in Scotts
Valley (which would necessitate a longer drive from the airport via Highway
17).
Aliprand said that, because of the crowded agenda for UTC #62, the formal
announcement listing the Directors whose terms expire at the end of the
year, and soliciting nominations, would be sent to Voting Members by
e-mail.
*** Action Item (Aliprand, Greenfield) ***
Send preliminary announcement re Board elections.
X3L2 Meeting Schedule:
Ed Hart, Chair of X3L2, had requested co-location of X3L2's meeting with
UTC #63, and suggested the following schedule:
Wed. 11/30, AM X3L2 meeting
Wed. 11/30, PM UTC Subcommittee meetings
Thurs. 12/1 UTC meeting
Fri. 12/2 X3L2 meeting
Ksar expressed support for co-location of the meetings. Hart's proposed
schedule was approved by consensus.
*** Action Item (Ksar) ***
Inform Hart verbally that UTC agreed to his proposed schedule.
*** Action Item (Greenfield) ***
Formal notification to Hart that UTC agreed to proposed schedule.
UTC #64 (March 1995):
Bay Area meeting. Taligent is willing to host. Friday, March 10, 1995 was
set as the date.
UTC #65 (June 1995):
Bay Area meeting. To be coordinated with X3L2. X3L2 may be meeting with
X3V1 in Colorado. Friday, June 2, 1995 was set as the tentative date.
*** Action Item (Greenfield) ***
Contact Ed Hart re X3L2 plans.
UTC #66 (September 1995):
Outside Bay Area meeting. Digital and Lotus offered to co-host this
meeting. Exact location (Boston or Nashua) to be settled by the host
companies. The meeting will be held late in September; Friday, Sept. 29
was set as the tentative date.
Note that UTC #62 should have been held in the Bay Area, but was held in
Toronto because Toronto's fall weather was preferred to winter. UTC #66
conforms to the regular cycle.
Report from the Unicode Office:
Greenfield reported that the Office receives 5-10 inquiries per day.
Favorable articles have appeared; Byte Magazine and PC Magazine will be
publishing articles, as will two Japanese magazines. A reporter from the
Wall Street Journal's Tokyo office asked for information.
Unicode Implementers' Workshop #6:
Because of the crowded agenda for this meeting, Honomichl had limited time
for this report. Aliprand said that a more detailed report would be sent
by e-mail to members. Tim Greenwood formally congratulated Lloyd Honomichl
for a job well done.
*** Action Item (Kernaghan, Honomichl) ***
Send more detailed report on UIW #6 to members.
Editorial Sub-Committee:
The full Unicode 1.1 will be published with an accompanying CDROM (which
has been agreed to by Addison-Wesley). Contents of the CD-ROM were
envisioned as the mapping tables, sample code, excerpts from documents,
etc. The deadline for submitting material for inclusion on the CD-ROM is
the end of October. Projected date for final text is the end of December,
with publication in 1Q95.
*** Action Item (All) ***
Anything that people wish to contribute should be sent in by the end of
October. Please make sure that your contribution is error-free.
*** Action Item (Taligent) ***
Taligent is taking charge of making sure the Han mapping tables are as
clean as possible.
*** Action Item (Greenwood) ***
Non-Han mapping tables need to be reviewed. Greenwood has this work item,
and is to contact McGowan.
*** Action Item (Corporate Members) ***
To put their corporate mapping tables on ftp site. Each corporate member
is responsible for accuracy of its mapping tables.
Ksar recommended including the workshop papers on the CD-ROM since they are
already in soft copy.
All UTC members were most concerned that accuracy be the prime goal of the
publication, and that if required the publication date be slipped to enable
a thorough review. This may require a special meeting, or perhaps an
extension of the December UTC meeting.
It was the sense of the meeting that final copy should not be sent to
Addison-Wesley without review by Member representatives, even if it meant a
later publication date. Gioia asked for a review period of 4-6 weeks, to
allow distribution within IBM.
Motion for Davis and Adams to prepare a publication schedule with
milestones, and send it to the Membership via e-mail, moved by Honomichl,
seconded by Moore and Batutis. Approved by consensus.
*** Action Item (Jenkins) ***
By Oct 3, notify Davis and Adams about the motion.
*** Action Item (Davis, Adams) ***
Establish a calendar with milestones for publication, including a period
for Membership review. A special meeting to review the text may be needed.
By Oct 7, send the calendar to potential reviewers.
Proposal for a "Missing Glyph" Font (UTC62-94-023):
This paper was prepared by Mark Davis (Taligent), who proposed a small
standardized set of glyphs, each representing a particular script block, to
be used when a font for the script is unavailable. Though you could see
the character itself, you could tell what its script block is.
This paper received a mixed response. Some of the glyphs that Mark had
chosen were considered too complex to show up well on video screen
resolutions. Several people felt that establishing such a font not an
appropriate activity for th e UTC, and that other methods of identifying a
script block were possible (e.g., an abbreviation based on the name of the
block).
There was no objection to including Taligent's font on the CDROM, but the
UTC will not endorse it as a standard.
East Asian Sub-Committee:
Report on IRG #3 in Beijing from Glenn Adams (UTC62-94-024) was
distributed.
IRG #6 is to be held in the United States. The Officers have discussed
whether the Consortium should co-sponsor with other organizations (e.g.,
ANSI and/or AFII), but no action has been taken as yet.
Jenkins reported that a mapping table between Unicode and GB12345 has been
published in Taiwan, but it is full of errors. This is not an official
mapping table compiled by the Consortium, but, because of the errors, it is
harmful to h ave it available. We need to work with the originators to
correct the errors. As an inducement to correct the table, we will offer
to make the table available at our the FTP site and include it on the CDROM
provided the errors are corrected.
*** Action Item (McGowan, Jenkins) ***
Put a copyright notice *in* each of the tables to deter proliferation at
multiple sites (and possible modification). This notice should include a
statement that the original source table can be obtained from the
"unicode.org" ftp site.
*** Action Item (Jenkins) ***
Contact the compilers of the Unicode-GB12345 mapping table. Offer to place
their table at the ftp site and on the CD-ROM if they clean it up.
Presentation on Canadian Aboriginal Scripts:
Dirk Vermeulen of the Canadian Aboriginal Syllabics Encoding Committee
(CASEC) presented the Committee's work on identifying a repertoire of
writing symbols used in various communities in the north of Canada to
write the languages of the Algonquian (Cree and others), Athapascan, and
Inuktitut peoples. CASEC has reworked its original character repertoire to
make use of composed character sequences.
Dirk works with a school board whose territory covers 400,000 square Km.
These very isolated communities make high use of fax and computers.
Probably about 70,000 people in all. The school systems each developed
computer material using the native scripts, but could not exchange data.
There was a conference in 1985, about 4 years study, went to Government
level in 1990.
Missionaries introduced the syllabic script based on Pitman shorthand
symbols for Algonquian languages. The base set moved to two other
language groups -- Inuktitut and Athapascan -- introducing new symbols.
Note that comparable language groups in the United States do not write in
syllabic script, but use Latin script.
Issue of composing or fully composed characters. CASEC would like all 651
precomposed characters in the BMP. Alternatives are put all precomposed
outside the BMP, or use composed character sequences, with the 274 base
characters and no n-spacing marks in the BMP. (These characters could also
be placed outside the BMP, but a request to add only 274 is likely to be
received more favorably than a request for 651 precomposed characters.)
General arguments are in favor of coding as decomposed: gives advantages
on searching, and accommodating new forms of characters that may be found
in isolated communities. Display technology is fairly stable for support
of decomposed encoding.
It was the sense of the meeting that the UTC would support a work item
proposal from the Canadian national body to WG2.
*** Action Item (McGowan) ***
Make sure the Scripts and Symbols SC has latest version of the CASEC work.
PDAM-1 (UTF-16) and PDAM-2 (UTF-8):
The U.S. positions on PDAM-1 and PDAM-2 were reviewed. The UTC
recommended removal of editorial and typographical comments to strengthen
the U.S. technical comments; editorial and typographical comments could be
submitted as a persona l contribution from Ed Hart (Chair of X3L2). Some
other clarifications were made.
*** Action Item (Jenkins) ***
Send UTC comments to Ed Hart for inclusion in U.S. position documents.
Implementation Sub-Committee:
John Gioia sent e-mail outlining the current state of the "Unicode
Implementation Guidelines" prior to the UTC meeting. He requested UTC
members to read what has been done, and submit new material (including
details of vendor-specific implementations). The target date for
completion is 4Q95.
Some of the proposed text repeats introductory material from "The Unicode
Standard," and could be dropped.
Moved by Greenwood, seconded by Honomichl, that Gioia publish a timeline
for the project, showing milestones. Approved by consensus.
*** Action Item (Gioia) ***
To request volunteers via a posting to unicore@unicode.org.
*** Action Item (Gioia) ***
Publish timeline per motion.
Proposal re Korean Hangul from Microsoft Corporation:
Composite of notes taken by Joan Aliprand, Steve Greenfield, Tim
Greenwood, and John Jenkins. Composite prepared by Joan Aliprand, and
posted to unicore@unicode.org on Monday, October 3.
This version incorporates the corrections/clarifications posted to
unicore@unicode.org by several UTC attendees. For consistency, "ancient"
has been changed to "old" throughout. Corrected lines are marked with '|'
in the left-hand margin.
===========================================================================
Alternatives for Encoding Modern Hangul
---------------------------------------
Jenkins listed the alternative solutions to the problem of encoding all
modern hangul. This list was compiled at Taligent, by Jenkins, Mark Davis,
| Lee Collins, and David Goldsmith. No additional alternatives were proposed
| at the UTC meeting, but Joe Becker suggested that the final category, "Do
| nothing," should be was divided into two subsections (see below).
The alternatives are designated "a" through "f". Alternative "f" (current
status) has two options (designated "1" and "2").
Although this list was presented in the middle of the UTC's discussion of
the issue, it is put here at the beginning because it is a key element.
a) add the additional 4,516 hangul to the BMP
b) Move all 11,172 hangul to another plane
c) Put the additional 4,516 hangul into another plane
| - This option would require use of UCS-4 or of UTF-16 (assuming
| successful ballot)
d) Copy all 11,172 hangul to another plane
| - This option would require use of UCS-4 or of UTF-16 (assuming
| successful ballot)
e) Permanently shrink the user zone in the Unicode standard and put the
additional 4,516 hangul into the former user space.
f) Do nothing (i.e., maintain current status)
1) Use conjoining jamos
2) Encode the additional 4,516 hangul in the user zone
===========================================================================
Presentation by T.J. Kang on Unicode in Korea
---------------------------------------------
Kang outlined the events that have occurred since June 1992 meeting of
ISO/JTC1/SC2/WG2 in Seoul, Korea.
Revision of KSC 5601 was completed after the 1992 WG2 meeting, and
published as KSC 5601-1992. This adds the 11,732 "Johab" precomposed
syllables.
Scope of the principal standards that include modern hangul:
KSC 5601-1987 has 2,350 precomposed modern hangul
KSC 5657 (a standard that no one implemented) has 1,800 modern and 2,000+
| old hangul
KSC 5601-1992 introduced a new coding scheme for all 11,172 modern hangul
ISO 10646 has 2,350 hangul (from KSC 5601)
1,800+ hangul (part of KSC 5657)
2,000+ old hangul of KSC 5657 were
deleted and replaced by modern
hangul
The hangul from KSC 5657 were selected on the basis of frequency. The set
of 2,000+ modern hangul which replaced the old hangul is in alphabetical
order (not by frequency of occurrence). The remaining 4,516 hangul from
KSC 5601 - 1992 take up three-quarters of the private use zone.
Ministry of Commerce and Industry set up a committee to study the future
character set needs of Korea. The Committee recommended (in its report
published in November 1993) that Korean should go its own way, and not use
the Unicode standard or ISO 10646. The modern part is finished; the
| Committee is now studying old hangul.
Korea's WG2 participants were initially excluded from the Committee's
deliberations, but were included after the Committee's report was
published. The general view was that the Korean delegates at the WG2
meeting in Korea had let the nation down by not getting full hangul set
into ISO 10646. There is enough flux within Korea that ISO 10646/Unicode
can possibly be set aside and ignored.
Microsoft Windows is a major platform for most computer users in Korea.
Currently, it supports only the earlier version of KSC 5601. Some Korean
companies are doing their own modifications using the full 11,000 hangul
(johab) of KSC 5601-1992. The dominant Korean word processing software
(between 65-85% of the population) developed by Angin (spelling?) does its
own character handling on DOS and supports all 11,172 johab and some
| old characters. Now porting to Windows - not using Windows text API for
text display. HanSoft is also writing a driver supporting all 11,172
johab hangul but with slightly different extensions to KSC5601-1992 (for
old hangul and Chinese character support). Standards people in Korea are
concerned about the proliferation of coding schemes.
The Korean national character code committee is wondering about proposing
the addition of a complete set of hangul to ISO again. The arguments for
encoding hangul are:
* economy of storage (one code, rather than a number of codes for
conjoining jamos); and,
* backwards compatibility (Microsoft is interested for this reason).
Koreans have not seen an implementation of Unicode/ISO 10646. Microsoft is
not sure whether it will have conjoining jamos in Windows NT.
The Korean national character code committee is responsible for reviewing
national standards as well as WG2 participation. There is a difference of
opinion in the Committee on the development of national Korean character
sets versus adoption of an international standard (i.e., a national version
of ISO 10646).
T.J. Kang requested support from the Consortium if the Korean national
standards body proposes addition of the 4,000+ hangul characters to the
BMP. The Korean national standards body does not want to propose this to
WG2 without Unicode Consortium support.
Becker: How stable is the 11,000 hangul set?
A (Kang with Hong): It is not an open set. The hangul repertoire is also
true for North Korea.
| Q. Is old hangul a separate issue?
A. Character coding is a passionate issue in Korea. There have been
features in the newspapers and on TV. Scholars want old hangul, as well as
Chinese (that is, hanja). The repertoire of 11,172 hangul meets only
modern needs. The need for old hangul is a minority opinion on the
character set committee. Because of the number and variety of old hangul,
conjoining jamos may be used to encode them.
Greenwood: A Korean colleague said that johab were in the KSC 5601-1992
standard as an appendix, and were designated as "for internal use only and
not for interchange."
A. This statement reflects a compromise. Government computers still use
the earlier version of KSC 5601, and the government wanted to enforce its
use for communication. Small scale LAN users, on the other hand, are using
the new standard.
Q. Use of private user space?
A. An out for the Koreans. Later, companies and Korean delegates felt
betrayed.
Is the inclusion of the missing hangul in the BMP "too good to be true"?
Ksar (in his ISO capacity as Convenor of WG2) pointed out that the Korean
delegates to WG2 had not said anything about this in over three years, and
have not asked for this to be put on the agenda of WG2.
Kang: Koreans feel that they have nothing to lose by asking the UTC for
support.
Presentation by S.G. Hong
-------------------------
The proposal is from Microsoft Corporation as a member company.
Unless we include the KSC 5601 characters in precomposed form, Microsoft
will not be competitive in Korea. Microsoft wants to comply with the
Unicode standard, and also provide backwards compatibility.
If a complete set of precomposed hangul are not included in the main code
space, Microsoft would have to support the conjoining jamos method. This
would mean that a printer driver (for example) would have to convert from
conjoining jamos to KSC 5601 -1992 encoding.
Jenkins: Why is using conjoining jamos a problem? To use 5601 a printer
driver has to convert from Unicode to 5601 fonts. Conversion has to be
made from either precomposed Unicode or conjoining jamos.
Hong: This may be a Microsoft-specific problem.
Honomichl: Are there things we are doing that we are not aware of and
| might cause us problems? He added: If so, it would be good to know
| about them (i.e., any problems arising from specific implementation
| choices that Microsoft may have identified while working on Korean.)
Hong: Microsoft needs to have 1:1 mappings from code page to Unicode in
driver APIs for printers, screens, etc. Looking for a trivial 1:1 mapping,
so can recompile to provide Unicode functionality.
Jenkins: Means that this (1:1 mapping need) is true for all Microsoft
Unicode implementations. The problem just surfaced in Korea.
Double API structure of Windows requires Unicode to be basically the same
as the "native" code page for any language. (That is, people would have to
actually rewrite their printer drivers, etc. if they could no longer make
casual assumptions about the structure of the code set.
Becker: Two different pleas: Why can't the current status (additional
hangul in private use area) get us somewhere?
A. Does not satisfy the belief of Koreans that the whole set should be in
there.
Becker: But why isn't it (current status) ok for Microsoft?
Hong: We want to comply with the standard and promote Unicode. Microsoft
has been promoting the Unicode standard to ISVs. But the Product
Development Group found problems: they say "cannot ship product." There is
debate within Microsoft whether to use Unicode or to use DBCS for Korean.
| Jenkins: Because Microsoft is using private user space for the
| user zone of Shift-JIS, there is a conflict with needs for Korean. There
| is insufficient room in the user zone for both Shift-JIS's user zone and
the 4,516 hangul. (Option f2 conflicts with Microsoft implementation for
Shift-JIS.)
| [Clarification: In subsequent e-mail, Jenkins noted that (a) IBM, and
| possibly other companies, are also mapping Shift-JIS's user zone into the
| Unicode user zone, and (b) everything else in Shift-JIS (i.e., outside
| of its user zone) is already in the Unicode standard.]
Jenkins presented the alternatives (see above), and said that Taligent does
| not consider alternatives b or e to be viable options.
Kang: Alternative d corresponds to a recommendation in the study issued by
the Korean character set committee.
Hong: Microsoft would prefer Alternative e (because of conflict between
Shift-JIS and hangul). This may be a viable option in Microsoft view.
Greenwood: Alternative e means a break with ISO 10646.
This point was discussed in detail. The private use zone is not part of
the conformance clause of ISO 10646, so such a change would not cause the
Unicode standard to be non-conformant (at least, legalistically). However,
Alternative e would mean a non-compatible upgrade of the Unicode standard.
Hong: Microsoft is looking for consensus on how to use user zone for
hangul. Cannot agree on Shift-JIS use.
The UTC saw several problems with Alternative e:
* The Unicode user zone is made permanently smaller;
* Breaks with ISO 10646;
* Breaks with existing implementations.
Problem of gaiji characters in Japanese applications.
Ksar: Where do UTF-16 and USC-4 fit in this? Has Korea considered a
Korean national variant of ISO 10646?
Hong asked for advice on strategies for the implementation of hangul.
Initial opinion of the UTC was that the best long-term strategies are:
* Alternative f1 (conjoining jamos); or,
| * Combined hangul on another plane (using UCS-4 or UTF-16).
| With respect to combined hangul on another plane, there was general
| agreement that Alternative b is untenable. Ksar pointed out that it
| would require changing code point assignments of ISO 10646.
When the eventual need to convert data from Alternative f2 (some hangul in
the user zone) is taken into account, UTC opinion was that the better
choices are:
* Alternative c (4,516 combined hangul in another plane); or
* Alternative d (all 11,000 hangul in another plane).
These alternatives parallel current combined single byte/double byte
systems, with which Korea has considerable experience. The alternatives
are also consistent with UTF-16, which has been approved by the UTC.
Alternative c was considered preferable to Alternative d, as it avoids
duplicate encoding of the same hangul.
McConnell said he is against putting hangul in extra planes, because they
are encoding variants, not presentation variants. Does not like the
prospect of multiple encodings (i.e., conjoining jamos and precomposed
hangul).
Jenkins: Prefers putting them on another plane to putting them in the BMP.
The problem with Alternative f2 (additional hangul in user zone) is that
users are not *required* to use particular encoding values. Because this
is user space, companies could declare their own arrangement for encoding
these characters.
Greenwood argued against changing the principles of the Unicode standard
just because of simplistic implementation choices.
Bennett asked Hong: What happens when you receive data encoded with
conjoining jamos?
Hong: Are member companies willing to pursue Alternative a (additional
hangul in the BMP proper)?
The consensus of the UTC was that Microsoft needs to present a detailed
cost/benefit analysis examination of all the alternatives, to explain why
Microsoft prefers Alternative a.
Jenkins pointed out that, in the short term, Microsoft can do Alternative
f2, and would be compliant with the Unicode standard.
The UTC needs solid reasons explaining why Alternatives c, d and f are not
going to happen in Korea.
Jenkins said that supporting Alternative a is telling us "you have to
choose between Korea and Taiwan" (which has proposed a collection of
additional ideographs). Alternative a would also mean rejection of the
German proposal for additional characters.
Gioia: This brings in an additional factor: What is happening at the ISO
level? The Koreans will have to compete with everyone else for the
unassigned code points of the BMP.
Ksar: Koreans have not even made a proposal to ISO for addition of the
4,000+ hangul to the BMP.
| Greenwood: If Korea wishes to pursue this request then the Korean
national standards body should propose the addition of the hangul to WG2.
It would be improper for the Unicode Consortium to make such a proposal.
[No UTC member disagreed with this statement.]
Hong: Will bring alternatives to Product Group, ask them to evaluate each,
and say how hard it would be to do each.
Ksar: It is important for Microsoft to continue to participate in the
Unicode Technical Committee and WG2. Unicode, Inc. is a liaison to WG2,
and so any resolutions of the UTC have to be presented to WG2 for a vote.
There are real advantages for a company to be part of this process.
Korea is not the only country that wants to add characters to the BMP. The
issues are described in ISO document N884 (copies were distributed at the
UTC meeting).
Microsoft needs to provide more information to convince the UTC that one
alternative is better than the others, and that this alternative is better
for other member companies as well as for Microsoft. (But then you need to
convince ISO.)
There is no question that the UTC is firmly committed to keeping ISO 10646
and the Unicode standard synchronized. Those present at the meeting
expressed vehement support for this.
Action item (Greenwood, Aliprand, Greenfield, others?):
Send copy of personal notes (draft Minutes in the case of Greenfield) to
S.G. Hong and T.J. Kang. [DONE per this composite]
Action item (S.G. Hong):
Prepare a detailed cost/benefit analysis examination of all the
alternatives. State which alternative is preferred by Microsoft (and why).
Give reasons why this alternative may be better for other companies too.
This analysis to be submitted to the UTC.
Other Items:
*** Action Item (Greenfield, Greenwood, Aliprand) ***
The minutes for this meeting are to be provided by Friday morning.
Let the Minutes show: With respect to Version 1.1, that the editorial
comments be passed onto the Editor and he shall take them accordingly.
*** Action Item (All members) ***
Please review the Unicode Character Property Data Table at the ftp site,
and send any corrections or feedback to Mark Davis by the end of October.
This table is to be published on the CD-ROM.
WWW Home Page:
During the lunch break, Tim Greenwood demonstrated a preliminary draft of a
Unicode Consortium home page for the World Wide Web. The text is extracted
from various published documents.
John Jenkins later remarked that Web browsers ought to be Unicode-enabled,
and suggested to John Gioia that IBM might want to consider this. Joan
Aliprand said that the Officers had already discussed this possibility, and
that any proposals should be coordinated through them.
*** Action Item (Aliprand) ***
Let Officers know about Jenkins' suggestion.
Meeting adjourned at 3:44 p.m.
=END=