> > On Wed 12-Mar-2003 at 05:12:50PM +0100, Thomas Baker wrote:
> > >
> > > The modeling issue is whether it makes sense to qualify the
> > > literal "2003-03-12" with "en-US", and Jon seems to confirm what I
> > > had suspected -- that it doesn't really "make sense"...
> >
> > My fear would be that it might give the impression that the
> > following is OK and that these are the same date...
> >
> >   <dc:date xml:lang="en-US">11-09-2001</dc:date>
> >
> >   <dc:date xml:lang="en-UK">09-11-2001</dc:date>
> >
> > I realise that we (the people on this list) won't get confused about
> > this (we all know that only W3CDTF dates are valid) but other people
> > might get the impression that the xml:lang attribute makes a
> > difference to the date format...
> Indeed.
> Simple acid test: Is this a piece of American English text? No, it isn't,
> therefore it isn't en-US.
> W3CDTF dates aren't even geared towards human-readers, while human-readable
> it would generally be best to translate it to a localised format for
> end-users.

> Besides, most applications looking for "en-US" should look for "en" if it
> can't find American English, then look for "en-*"[1], then "i-default", then
> something with no language, then either assume nothing is available or
> prompt the user with which languages it can provide information in (the
> latter would depend strongly on the purpose of the application). Basic
> send-strict receive-liberal surely?

Excuse me...DC is not just an English dialects and spelling fun club.
You may infer xml:lang="en-US" ===> xml:lang="en"
No such rule is true for xml:lang="de"

How to get around with such very basic ambiguities is regulated via
RDF refering to xml-schema datatypes.

We can largely forget about clumpsy W3CDTF and use
the xml schemas datatypes on date/time instead.

> [1] Obviously there'd be nothing wrong in it applying rules like "en-IE is
> closer to en-GB than en-US if it can.