On Thu, 20 May 2010 13:52:08 -0500 Anthony Liguori <anth...@codemonkey.ws> wrote:
> On 05/20/2010 01:47 PM, Luiz Capitulino wrote: > > On Thu, 20 May 2010 11:55:00 -0500 > > Anthony Liguori<anth...@codemonkey.ws> wrote: > > > > > >> On 05/20/2010 11:27 AM, Luiz Capitulino wrote: > >> > >>> On Thu, 20 May 2010 10:50:41 -0500 > >>> Anthony Liguori<anth...@codemonkey.ws> wrote: > >>> > >>> > >>> > >>>> On 05/20/2010 10:16 AM, Paolo Bonzini wrote: > >>>> > >>>> > >>>>> On 05/20/2010 03:44 PM, Luiz Capitulino wrote: > >>>>> > >>>>> > >>>>>> I think there's another issue in the handling of strings. > >>>>>> > >>>>>> The spec says that valid unescaped chars are in the following > >>>>>> range: > >>>>>> > >>>>>> unescaped = %x20-21 / %x23-5B / %x5D-10FFFF > >>>>>> > >>>>>> > >>>> That's a spec bug IMHO. Tab is %x09. Surely you can include tabs in > >>>> strings. Any parser that didn't accept that would be broken. > >>>> > >>>> > >>> Honestly, I had the impression this should be encoded as: %x5C %x74, > >>> but > >>> if you're right, wouldn't this be true for other sequences as well? > >>> > >>> > >> I don't think most reasonable clients are going to quote tabs as '\t'. > >> > > That would be a bug, wouldn't it? > > > > Tabs are valid in JavaScript strings and I don't think it's reasonable > to expect that a valid JavaScript string is not a valid JSON string. IMO, we should do what the spec says and what bug free clients expect, what we consider reasonable or unreasonable is a different matter. I would be with you if the spec was proved wrong, specially if reference implementations out there didn't follow it either, but everything I found so far shows this is not the case. Another example: http://www.json.org/json2.js Search for 'character substitutions'.
