JSON parser grammar
dean at deanlandolt.com
Tue Jun 22 20:17:04 PDT 2010
On Tue, Jun 22, 2010 at 10:20 PM, Oliver Hunt <oliver at apple.com> 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?
> 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.
There are countless JSON parsers in the wild -- likely > 1 for almost every
obscure language in existence, not counting all the one-offs. Any number of
these were written with the expectation of not expecting control characters
-- not too long ago I wrote a .NET streaming parser that I'm fairly sure
would blow up at the first sight of a \t.
I know many of us in the ES community tend to prefer a Postel's Law approach
-- and as long as tabs are always properly stringified it's not a huge
interop problem. Still, an argument could be made that with browsers
accepting known-bad input (per the JSON spec) it
could encourage fragmentation (albeit it minor) of the one format that's
really delivered on the promise of true interoperability.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss