> You display little real knowledge of the CLDR project or the relationship > between the Unicode Standard and ISO/IEC 10646. Your statement about ISO > 15924 happens to be accurate (but a broken watch is correct twice a day).">

Unicode Mail List Archive: Re: Exemplar Characters (original) (raw)

Next message: Jony Rosenne: "RE: Hebrew script in IDN (was Exemplar Characters)"

From: "Mark Davis" <mark.davis@icu-project.org>
> You display little real knowledge of the CLDR project or the relationship
> between the Unicode Standard and ISO/IEC 10646. Your statement about ISO
> 15924 happens to be accurate (but a broken watch is correct twice a day).

I know that you are leading the CLDR project, but your statement about my
ignorance of the project is wrong. I know it since its first introduction,
when it was not even named CLDR, and long before the project was moved to
the Unicode Consortium.

I even knew and participated to the two past i18n projects that were born in
the Linux community, and when they joined in the openi8n.org joint project,
and then when such alpha code was integrated in ICU (I also knew ICU
separately when it was still in IBM alphaWorks, and even a littel before,
when it was still not open-source, but discussed in preliminary related
lists in various Linux, BSD, Solaris and AiX developers communities that I
was monitoring at that time, years ago).

I have not participated a lot in the development of the LDML syntax only
because it's an internal cooking which gets adapted over time to help
representing the concepts that are progressiveley integrated in the CLDR
project. And In fact I doubt that LDML will be used in applications for
something else than the management of the common CLDR database itself.

The CLDR project is not a standard, and I hope it will never be. What it is,
it's a shared database of information that allows collaboration between
various vendors so that they complete their implementation to support more
languages and agree on using the same terminology and conventions that will
work corectly for most users. The CLDR project is aimed at serving the
users, not aimed to be used asa technical specification for developers.

What this means is that the current XML and LDML syntax can be changed at
any time for other better new technology if needed. What is important in the
CLDR project is the database of information, not its internal technical
specification, so LDML-related things like the syntaxof locale identifiers,
and inheritance of locales is just internal cooking to represent the
information. For users they don't see that and don't need to see that.

An implementation can then safely state that it implements the CLDR
database, without even using its internal LDML syntax representation, or the
same locale identifiers (which will change anyway over time, when RFC 3066
will be updated, and locale resolution algorithms will be finally updated).
The same application could as well use its own numerical locale identifiers,
or could not implement at all the locale resolution algorithm (only
delivering final localisations in each precise locale).

I see personnaly no interest in attempts to integrate the CLDR database, or
its data model, or its internal LDML specification as part of the Unicode
standard. The two projects must continue to evolve separately, and there's
no requirement in CLDR for example to be indefinitely bound to Unicode rules
regarding regular expressions, or non-use of rich-text features that are
forbidden in the Unicode standard.

The two projects have very distinct goals and serve other purposes. The
Unicode standard does not attempt to define locales for example, because it
can't define what is a locale, without making false assumptions about other
third-party standards for which it is not authoritative. Any attempt to do
that would mean that many applications would become non-conforming either to
the Unicode standard or either to third-party standards.

This archive was generated by hypermail 2.1.5: Sat Nov 19 2005 - 07:29:59 CST