Re: [Json] I-JSON Tpic #2: Top-Level

[Nico Williams <[e-mail]>]

On Tue, Apr 29, 2014 at 10:40 PM, Tim Bray <[e-mail]> wrote:
> I’m sorry, but the central idea of I-JSON is to explicitly rule out all the
> interoperability problems identified in RFC7159: How to produce
> maximally-interoperable JSON.  7159 specifically says that for
> interoperability a JSON Text should be an object or array, and the idea of
> making I-JSON less constraining totally defeats its purpose.  This is just
> not a reasonable direction to be going.

Applications that use JSON -or any other encoding system for
structured data- need to agree on schema to begin with.

Yes, it's true that a human can eyeball a JSON text, or a dump of
ASN.1 BER/DER/CER encoded data, or..., and get a pretty good idea of
the meaning of various artifacts.  But by and large it's applications
that consume these things, not humans.  And applications, not being
humans, need to agree on schemata.

Usually schema signalling is done out of band, and you have dropped
your earlier proposal to do I-JSON signalling in-band.  Why do we need
to do anything else at all regarding this?  (That's not rhetorical.  I
want to understand just why we should do what you propose.)

Extensibility of schemata is a separable issue; we should separate it.
 I agree that uses of JSON should generally have a default implied
extensibility rule, a-la modern ASN.1 -- i.e., ignore unknown names in
objects -- all objects most likely.  But that has nothing to do with
the top-level being an object, which is why it's separable.

Nico
--