Re: [Json] JSON Schema Language

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

Lets back up here a moment.

JSON is actually more than one thing. It is:

* A data model
* A lexical token specification
* A serialization

For the Mesh I take the JSON data model and extend it to distinguish
integers from floats and binary encoded blobs from strings via base64url
encoding. I also extend the lexical token specification so that I do not
have to base64 encode binary data blobs. Which is the chief barrier to use
of JSON for crypto.

I am writing my own serializer/deserializer and my own lexical token
analyzer. But that part is really not well grounded in JSON tooling as it
exists in the wild (yet). The aim of JSON-B/C is to be plug-compatible with
JSON so that it is possible to take an existing encoding and just drop in a
JSON-B handler.

Looking at the JSON tools out there, I see that most of them simply take
the input stream and turn it into a parse tree that supports search path
type accessors. That is not the approach I like but it is what folk working
in scripting languages usually want.

>From an interop point of view, any application that relies on being able to
round trip integers that exceed the IEEE float mantissa capacity is going
to break. That is just a fact of life. Another fact is that I have never
found a use for a float in any protocol specification.


Serializations and encodings are important. But there is no point in making
a fetish of finding the one true encoding. The Mesh uses JSON/JSON-B for
all its native encodings. But the Mesh tools have handling for ASN.1,
RFC821, RFC822, TLS and will soon have to add iCal/vCard because they are
all needed in the wild.

I think a JSON schema is a mistake at this point. We should look at writing
a general schema language that is a good schema language and has the
ability to specify ASN.1 or XML schemas or anything else that might need to
be specified.

The world is focusing on JSON for a reason but I think it is the JSON data
model we are actually focusing on rather than the JSON serialization. And I
don't think that insisting that nobody ever touch the original perfection
of JSON encoding is helpful either. All that is doing is ensuring that
instead of there being one JSON/2.0 there are dozens and more are being
added all the time.