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
