W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 1997

Re: Requirements Open Issues from Orem

From: Martin J. Duerst <mduerst@ifi.unizh.ch>
Date: Wed, 23 Jul 1997 12:19:55 +0200 (MET DST)
To: Judith Slein <slein@wrc.xerox.com>
cc: w3c-dist-auth@w3.org
Message-ID: <Pine.SUN.3.96.970722212736.245D-100000@enoshima>
On Mon, 21 Jul 1997, Judith Slein wrote:

Here are some comments on Internationalization:

> Internationalization
> The consensus of the group at Orem was that we should stay away from issues
> around variants, which are not specific to internationalization and would
> add enormously to the work of WEBDAV.  Jim will make sure that this position
> is acceptable to the area directors.

I can understand this, but I am not at all happy with it. Variants
are not only something that is very valuable for internationalization.
They turn up in many web projects, and do so usually long before
a project starts to use various language versions. For examlpe,
most even slightly serious web projects have frame and noframe
versions. In HTTP 1.1, negotiation (which is basically variant
negotiation) is present in all kinds of ways.
If Webdav doesn't deal with variants, or not at least has an idea of
how it could deal with it in a future version, this would really
be a pity.

> The question was raised whether we need to be concerned about collation.  We
> think that we do not -- we do not sort any query result sets, and we do not
> define greater-than or less-than operators for pattern matching.

That looks like a very reasonable answer. However, you should also
consider whether you have, or need, various degrees of "equality"
(the easiest example of this would be case-insensitivity, where
"A" == "a"). These things are also language/locale-dependent.

> We think that we need only to insure that any information intended for user
> comprehension should be expressed in a way that makes it possible to display
> the information in any desired writing system and language.  The proposed
> internationalization requirement is the following:
> "All information intended for user comprehension must be expressed in one of
> the ISO-10646 character sets and must have a language tag." 

Not too bad. But ISO 10646 defines the Universal Character Set (UCS),
so "one of the ISO-10646 character sets" is somewhat out of place.
This part of the requirement should probably read:

"For transmission of information intended for user comprehension,
the full Universal Character Set (UCS) [ISO 10646] must be available."

As for language tags, this is not so easy. For error messages and the
like intended for the user, you need language negotiation (i.e. the
client tells the server what language it would like to get the
messages in; the server tells what language it will actually use).
Once negotiatied, there is not a big need to tag each and every
message. For identifier-like components, such as resource names,
language taging can be dangerous, because binary comparison
of the identifiers will not work anymore if the language tag
is seen as part of the identifier. There are many other things
that affect the usefulness and applicability of language tags
or language information in general. Probably, writing something

"Language information and negotiation must be available where

is more close to reality and more flexible.

Regards,	Martin.
Received on Wednesday, 23 July 1997 06:21:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:11 UTC