Re: [Json] Consensus on JSON-text (WAS: JSON: remove gap between Ecma-404 and IETF draft)

On Mon, Dec 02, 2013 at 04:30:09PM -0500, Phillip Hallam-Baker wrote:
> Since we are talking about a serialization format, the distinction between
> unordered sets and lists cannot occur at the wire level and this is where
> we need interoperation.

But it can be part of the on-the-wire description.  See below.

> One of the things I think we have learned from JSON is that a
> self-describing format only needs to specify the abstract type of the datum
> and not the representation.

Self-description is a continuum.  Some ASN.1 encoding rules can encode
quite a bit of a schema on the wire -- clearly there's a point at which
the resulting redundancy causes problems.  But it's also true that
having a large subset of the schema in the serialization can be useful
(e.g., for generic "dump" tools).

Given the prevalence of languages like Python, a "set" type will no
doubt seem useful to some!  Heck, the ability to use non-string values
as keys (names) for objects would be nice too -- anyone who's spent much
time with Python and JSON has wished for these things.  JSON alone is
insufficiently expressive for "pickling" Python values; JSON with a fair
bit of convention layered on gets closer to being good enough for
pickling Python values.

Context will affect how much of the schema you or I will find desirable
to see appear redundantly on the wire.  But mostly I agree with you:
"datetime" and such are interpretations of more basic datatypes, and so
they belong in pre-agreed/documented schema rather than on the wire.
Indeed, datetime/timestamp could be either strings or numeric, and still
be understood correctly in context.

> There are many data encodings on offer but I would like to be able to write
> one decoder that can consume a data stream that contains basic JSON data
> and JSON with extensions. This makes negotiating an encoding in a Web
> service easy, the consumer states which encodings are acceptable and the
> sender makes sure what is sent is compatible, downgrading the encoding to
> the level accepted if necessary.

Yes.  Though, really, the main thing that's missing is chunked
(indefinite-length) unescaped binary data.  That's the thing that's
difficult/expenside to deal with in JSON (or XML, for that matter).
Bulk data transfers do matter.  (And if one is going to add that to any
serialization, then plain binary-coded integers and IEEE754 doubles may
be much better, perf-wise, than decimal encodings.)

Nico
--

Received on Monday, 2 December 2013 22:48:31 UTC