JSON parser grammar

Luke Smith lsmith at lucassmith.name
Tue Jun 22 20:23:52 PDT 2010


On Jun 22, 2010, at 7:20 PM, Oliver Hunt wrote:

>
> On Jun 22, 2010, at 7:07 PM, Dean Landolt wrote:
>
>>
>>
>> On Tue, Jun 22, 2010 at 9:34 PM, Oliver Hunt <oliver at apple.com>  
>> wrote:
>>
>> But that's the rub -- the JSON spec cannot be changed. It  
>> (intentionally) has no version number. ECMA could superset it -- ES- 
>> JSON, if you will -- which could specifically allow \t, but this  
>> could not strictly be considered JSON, and would break in many JSON  
>> parsers in the wild.
>>
>> Perhaps there's value in ECMA taking on such a task (they're in a  
>> unique position to get real traction behind a superset of JSON, and  
>> we all have a wishlist of JSON extensions). But it certainly  
>> wouldn't be JSON.
>
> I just looked through a few of the json parsers listed on json.org,  
> and of the sample I looked at all accept tab characters.  Which  
> parsers don't?

Browser native implementations are a recent development and are  
subject to ES5, not just RFC 4627, so comparing to non-browser libs is  
a bit of an apples and oranges comparison (or pears and asian pears  
perhaps).

>
> As far as I can tell, all the major browsers accept tabs, as do many  
> other json parsers, at brief inspection it seems that the defacto  
> (vs. actual) JSON spec allows tabs.

The language in the ES5 spec (vs 4627) is pretty clear with regards to  
conformance, and there are plenty of other violations in every browser  
implementation that still need to be ironed out, so labeling the  
status quo as defacto seems premature.  It seems to me that each  
vendor has holes to patch in their implementation and it just so  
happens they all have this one.

And regarding js library abstractions, I disagree that there is enough  
stability in the JSON implementations to state that major libraries  
*rely* on the parsing of tabs.  I think "tolerate" is closer to the  
truth.  I certainly do not rely on native implementations continuing  
not to conform to a spec that, relatively speaking, is fresh out of  
the gate.  I would rather see the implementations get cleaned up and  
follow spec than agree this early to disregard it.

L

>
> --Oliver
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100622/a85917d4/attachment.html>


More information about the es-discuss mailing list