 |
 |
> > > 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. rs > > [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. > >