Re: Hack for JSON sequences with trailing commas?

[Barry Margolin]

In article <mailman.4627.1533257510.1292.help-gnu-emacs@gnu.org>,
 Drew Adams <drew.adams@oracle.com> wrote:

> > > > 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.

The primary use of JSON is for communication between unrelated code, 
e.g. Javascript clients using PHP APIs. If you're creating JSON, you 
can't usually depend on it being parsed by a particular application, 
which might use a more permissive parser.

If you're designing a self-contained system where you control both the 
creator and parser, then you can do anything you want. The purpose of 
standards is to ensure compatibility between code from different 
creators.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***