help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Hack for JSON sequences with trailing commas?


From: Drew Adams
Subject: RE: Hack for JSON sequences with trailing commas?
Date: Thu, 2 Aug 2018 17:51:35 -0700 (PDT)

> > > JSON is a very limited subset of Javascript notation for literals. Many
> > > things that are allowed in Javascript source code are not allowed in
> > > JSON. The reason is presumably to simplify the design of JSON parsers --
> > > they don't have to deal with all possible input formats.
> >
> > Yes, but there is a difference between JSON as defined by its standard
> > and JSON as it is used in practice in many situations. The former is more
> > strict than the latter.
> >
> > Here is one description of possible differences between the strict syntax
> > of the standard and a lax syntax (one that does allow an extra, final
> > comma):
> >
> > https://docs.oracle.com/en/database/oracle/oracle-
> database/18/adjsn/conditions
> > -is-json-and-is-not-json.html#GUID-1B6CFFBE-85FE-41DD-BA14-
> DD1DE73EAB20
> 
> I think Oracle is unusual in being so permissive. I don't think the JSON
> parsers in PHP, Python, or Javascript allow as much as Oracle does.

It's only permissive if/when you want it to be. You can easily get strict 
behavior (i.e., per the JSON standard). IOW, you have a choice.

And what you want can depend on what you're doing. You might want to be able to 
store documents that are not strictly well-formed but are well-formed according 
to the lax syntax. But you might also want to process such stored documents in 
various ways, some of which accept only documents that are strictly 
well-formed. You can specify the behavior you want for storing and for various 
operations.

> I think the only common extension to JSON that was commonly allowed was
> allowing the top-level value to be something other than an object or
> array. The JSON spec was recently updated to legitimize this.

Yes, that's something different. The JSON spec is one thing. Uses of JSON data 
in practice are another thing. Only a subset of such uses require documents 
that adhere to the standard. Sometimes you can't control the kinds of documents 
you receive, but you want to be able to process them whether they strictly 
conform to the standard or not.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]