Re: [Json] On flat vs nested JSON encoding style

[Phillip Hallam-Baker <[e-mail]>]

On Fri, Feb 5, 2016 at 2:35 AM, Tim Bray <[e-mail]> wrote:
> Well, over at AWS, I’ve just helped launch an experiment in doing things at
> a large scale exactly the way PHB recommends against :)  Check out our
> “CloudWatch Events” JSON at
> http://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/CloudWatchEventsandEventPatterns.html
>
> We have millions & millions & millions of these flowing through the pipes
> already, with many more to come.

If you use a particular tool and that is the only one you understand,
you won't see the problem.

This is a standards organization. So the architecture should impose
the fewest constraints on implementation as possible.

Very small changes in implementation can make a huge impact on
implementation. The reason ASN.1 is hated with a passion by pretty
much all crypto folk who have implemented it is one line in the
definition of DER encoding. The use of definite length encoding over
indefinite length had virtually no impact on X.509v1. Either could
have been chosen as canonical. The one they chose has a dramatic
impact on complexity of the implementation in X.509v3.


What you are arguing for is that you want to write your structures like this

struct fred { int a, int b, int c}

{ "a" : 1, "b" : 2, "type" : "fred", "c" : 3}

Now you might think that is a reasonable way to present the data in a
spec but most of us would say that it is hard to follow. The important
information of the type of the structure is buried in the
serialization stream.

What is hard for a human to work out imposes unnecessary constraints
on computer implementations. It makes JSON a special case for no good
reason.

I have a tool that can serialize/deserialize to JSON, ASN.1 or XML
from a schema that is essentially just a description of the data types
to be passed on the wire. It doesn't support unrestricted XML and
implementing PKIX requires the schema to be decorated with additional
information to define encoding details.

The reason I like JSON is precisely the fact that right now, it does
not require any decoration and the only constraint it imposes is that
the tag to describe the data structure precede the data being
described.