Re: first para

> Needs wordsmithing to remove the "plain literals are typed literals"
> connotation. It also gives the connotation that typed literals and
> plain literals have disjoint value spaces.  (Yes it doesn't say that,
> but people will read that into it.)  It also retroactively turns a "may"
> into a "does" for the relationship between plain literals and NL
> utterances.

Okay, I've made some changes which make it read better, and that I hope
address your points.

> Bad Sandro!
> 
> This needs to be changed.  I would go back to the previous version. 

The old version wasn't great either. Its approach to the I18N issues
provoked two LC comments, as I recall, at least one of which (MSM)
required changes other folks would rather not have, eg talking about
Ruby.  (The main discussion was before you joined this list, though,
Peter.)  As of this morning, Michael Sperberg-McQueen re-iterated to me
[1]:

   The fact that the type being defined pairs a string with a language
   tag in order to serve as an improved "mechanism for representing text
   in different languages ... and other kinds of language-specific
   processing" seems to me enough reason to point out ways in which the
   type being defined may be unsuitable for some languages, writing
   systems, and/or texts.  (And, yes, reason enough to be unhappy if the
   spec says nothing about it.)

Mostly, I think the cleanest response is to further de-emphasize I18N,
clarifying that improving I18N support was not the goal here.  I've
tried to do that in my text.

     -- Sandro

[1] This was off-list and is quoted with permission.

Received on Friday, 29 May 2009 00:06:05 UTC