Subject: PaceSimpleLanguageTagging status

From: Tim Bray <[email-masked]>
Date: Mon, 24 Jan 2005 16:17:38 -0800

Not yet taken up by the WG, depends on the discussion that comes with 
this call. Same rules as all the others: there has to be a positive WG 
consensus that each adds to the base specification.  -Tim

---

From: Sascha Carlin <[email-masked]>
Date: Tue, 25 Jan 2005 02:00:07 +0100

> consensus that each adds to the base specification.  -Tim

+1, at least for atom:language inside the header. For elements, well, there 
_are_ use cases for elements in different languages, so, since it is optional, 
+1 again.

Regards, Sascha

---

From: Martin Duerst <[email-masked]>
Date: Tue, 25 Jan 2005 14:30:51 +0900

>
 >+1, at least for atom:language inside the header. For elements, well, 
there _are_ use cases for elements in different languages, so, since it is 
optional, +1 again.

-1, or better, -2. Inventing things like atom:language when there
is xml:lang is just completely useless and superfluous.

Regards,    Martin.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 25 Jan 2005 08:15:00 +0100

>is xml:lang is just completely useless and superfluous.

Could you clarify how xml:lang solves the problems stated in the Pace?
The alternatives to the Pace would seem to be either restrict xml:lang
to specific elements or implementations that lose xml:lang information
or, in an authoring scenario, do not allow to use it -- i.e., ignoring
the problem in the specification. Neither of which is really helped by
xml:lang, so your comment seems a bit weird.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: "Bob Wyman" <[email-masked]>
Date: Tue, 25 Jan 2005 03:00:00 -0500

I am strongly opposed to PaceSimpleLanguageTagging.

Atom should not repeat the mistake made by RSS V2.0 and others in inventing
new and inadequate mechanisms for language tagging. xml:lang is the
appropriate means to handle language tagging.

The Pace identifies some "costs" of the xml:lang mechanism. These costs are
well known and have been for some time. Their itemization does not compel a
"solution" or even that the costs be addressed. They are simply the
well-known and inevitable costs that are associated with providing I18N
support in a flexible and comprehensive manner. Individual applications will
have to decide whether they are willing to support the maximum degree of
flexibility provided for in the specification, however, it would be
inappropriate at this point to compromise I18N support in the future due to
the limitations of existing applications.

Users who have issue with database systems that do not record "language"
information in addition to character set should address their concerns to
the vendors of the database systems -- not to the Atom Working Group. The
issue of I18N has been under active discussion since at least the early 80's
and we've been writing code that addressed both character set and language
ever since then (think collating sequences...). It's about time that folk
woke up and addressed I18N instead of trying once again to push it off as
"too-hard". Just as character set is a property of any string, language
needs to be a property of most strings. That's the way the real world works.

		bob wyman

---

From: Martin Duerst <[email-masked]>
Date: Tue, 25 Jan 2005 18:26:19 +0900

Hello Bjoern,

For more details, please see my earlier message at
http://www.imc.org/atom-syntax/mail-archive/msg12198.html.
Please comment on the specific points mentioned there.

Regards,     Martin.

At 16:15 05/01/25, Bjoern Hoehrmann wrote:
 >Bj$B‹S(Bn H$B‹I(Brmann $B%-(B mailto:[email-masked] $B%-(B http://bjoern.hoehrmann.de
 >Weinh. Str. 22 $B%-(B Telefon: +49(0)621/4309674 $B%-(B http://www.bjoernsworld.de
 >68309 Mannheim $B%-(B PGP Pub. KeyID: 0xA4357E78 $B%-(B http://www.websitedev.de/

---

From: David Powell <[email-masked]>
Date: Wed, 26 Jan 2005 01:29:08 +0000

> I am strongly opposed to PaceSimpleLanguageTagging.

I had two problems with xml:lang:

One was implementation difficulty - I think that the level of language
support in Atom seems a bit unbalanced. On one hand we can language
tag everything anywhere - which is a good thing, but unprecedented for
syndication formats; on the other hand we can only have a single title
and a single alt link. Perhaps the idea is that there should be
multiple feeds and language selection should be done outside Atom, eg
with Accept-Language, but this doesn't seem to fit well with "xml:lang
everywhere", as there isn't necessarily a language for a feed - only
for the components of it.

Anyway, I've heard enough arguments in favour of xml:lang that I'll
accept that it is a necessary cost.

My other issue was that we need to state which core elements are
language sensitive and which are language neutral, otherwise
implementors will guess and language tags will get lost. We also need
to state what happens to extensions. I'd suggest that if we go with
PaceExtensionConstruct, then Simple Extension constructs are language
sensitive (although I really don't mind them being language neutral
either - I'm not convinced either way). Structured Language constructs
MAY be language sensitive (so if you don't know how to interpret them
specifically, then you MUST preserve the language tag).

So I am now -0.5 to PaceSimpleLanguageTagging, but I think that there
are still some issues, so I think we need another Pace that makes it
clear what xml:lang applies to.

BTW:

When no xml:lang is in context, is the default language be
language neutral (ie: xml:lang=""), or is it determined by the
envelope, eg: a HTTP Content-Language header?

-- 
Dave

---

From: David Powell <[email-masked]>
Date: Wed, 26 Jan 2005 01:34:55 +0000

> is xml:lang is just completely useless and superfluous.

Well, it was more like a blatantly re-badged dc:language than an
invention, but I'll agree that it probably isn't the best solution.

I think we should instead decide what core elements are affected by
xml:lang, and whether extensions are affected.

-- 
Dave

---

From: Walter Underwood <[email-masked]>
Date: Tue, 25 Jan 2005 18:26:45 -0800

Here is a middle ground. We allow xml:lang, say that it SHOULD be
used at the feed and entry level, and that it MAY be used elsewhere,
but be aware that the information may be lost when translated to
other formats.

I'm actually +1 on the original proposal, because it is a good
fit to what search engines will do anyway. But I'd be +0.5 on
the modified one above.

wunder

--
Walter Underwood
Principal Architect
Verity Ultraseek