On Tue, Jun 22, 2010 at 10:20 PM, Oliver Hunt <oli...@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 <oli...@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.
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
