Subject: Re: [apps-discuss] Describing JSON document formats

From: Ladislav Lhotka <[email-masked]>
Date: Sun, 2 Dec 2012 10:09:41 +0100

On Nov 30, 2012, at 7:45 PM, Nico Williams <[email-masked]> wrote:

> On Fri, Nov 30, 2012 at 11:13 AM, Phillip Hallam-Baker <[email-masked]> wrote:
>> I think it would be very useful to have a mechanism that allowed JSON
>> formats to be mapped onto data structures and back.
> 
> Agreed.
> 
>> I think that a mechanism that looked anything like XML Schema with the
>> maximum and minimum values for integers or with regular expressions and such
>> should be left at the door.
> 
> Well, type constraints are a good thing.  If you know that some number
> will be 0..2^32 - 1 then you can use a uint32_t in a C implementation
> -- at least you'll want to distinguish between integer sizes, bignums,
> and so on.  Yeah, you don't need min/max to convey integer size.
> 
> The key is that the JSON syntax/schema/whatever map easily onto your
> implementation language, and given the programming languages we all
> typically deal with (from C to Python, JS, Ruby) I think we need
> something ASN.1-ish, just not ASN.1 itself, and very light-weight.
> 
> But, really, something ASN.1-ish, minus the awful syntax, minus the
> tags, and all that.  We might call it JASN, say (heh).  All we need is
> to be able to specify messages as being arrays or dicts, and if arrays
> of what type (including "any"), and if dicts what keys are allowed,
> which are required, which are optional, and their value types, and
> whether unknown keys are allowed.  Even if that's too much info, the
> default should be that everything is optional, value types are "any",
> and let your implementation impose any actual constraints however you
> like.  And if you have a protocol that could really use constraints in
> the schema, use them.

In my opinion, YANG [RFC 6020] should satisfy most of the requirements - and it can also be extended if necessary. YANG can be used for modelling JSON text via [draft-lhotka-netmod-yang-json-00]. Paradoxically, YANG is probably a better fit for JSON than for XML.

The example in the cited I-D, sec. 3.4 [*], shows a sample of YANG features and how they are mapped to JSON.

Lada

[*] http://tools.ietf.org/html/draft-lhotka-netmod-yang-json-00#section-3.4

> 
>> I also think that there is no need to use JSON syntax for the purpose of
>> defining the data structures.
> 
> But since you can parse it you can easily turn it into what you like:
> 
> { 'type' : 'struct', 'name' : 'Account', 'fields' : [ [ 'Username',
> 'String' ], [ 'Realm', 'String' ], [ 'Created', 'DateTime' ] ] }
> 
> Done right it can be made real easy to add implementation-specific
> directives ("represent this number as uint32_t, that one as uint64_t,
> this dict as a struct, that dict as a hash table, ...").  To me this
> is important: the lack of a decent way to add implementation
> directives to ASN.1 is one of the many problems with ASN.1.
> 
>> Good:
>> 
>> Structure Account
>>    String Username
>>    String Realm
>>    DateTime Created
>> 
>> 
>> Bad:
>> 
>> Structure Widget
>>    Integer Height { min=1, max=142}
>>    Integer Width {min=1, max=23}
> 
> If you don't care about the constraints, don't implement them, no?
> And if nobody cares, for some protocol, then don't declare them.
> 
>> Schema validation is bunk.
> 
> Oh, well, if you've got complex config file languages then you kinda
> want schema validation as it becomes a configuration linter.  I'm
> bored of writing config file parsers, validators, ...
> 
> Nico
> --
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Andrew Newton <[email-masked]>
Date: Mon, 3 Dec 2012 11:49:02 -0500

On Fri, Nov 30, 2012 at 11:34 AM, Cyrus Daboo <[email-masked]> wrote:

> My question is, is there any right way to describe a JSON document format?
> I know there are various JSON schema proposals out there, of which
> draft-newton-json-content-**rules was the one I liked the most, and
> obviously I would be interested in seeing that document proceed. Any
> thoughts?
>

Hi Cyrus,

I'll be updating the content rules draft soon. But regarding your question
about there being a right way, my opinion is that there need not be only
one way to do describe JSON. Like programming languages, schema
languages/formats should be used as appropriate.

Thanks for taking a look at the JSON content rules draft.

-andy

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 03 Dec 2012 12:06:11 -0500

Hi Andrew,

--On December 3, 2012 11:49:02 AM -0500 Andrew Newton <[email-masked]> wrote:

> I'll be updating the content rules draft soon. But regarding your
> question about there being a right way, my opinion is that there need not
> be only one way to do describe JSON. Like programming languages, schema

Thanks for putting that draft together. I do prefer it amongst all the 
other JSON "schema" type proposals I have seen. If you have a chance I 
would appreciate you reviewing the usage in 
<https://datatracker.ietf.org/doc/draft-douglass-timezone-service/> to make 
sure that looks right.

Have you put together any sort of validation tool for the content rules 
syntax? It would be good to have something like that.

-- 
Cyrus Daboo

---

From: Andrew Newton <[email-masked]>
Date: Mon, 3 Dec 2012 12:33:48 -0500

On Mon, Dec 3, 2012 at 12:06 PM, Cyrus Daboo <[email-masked]> wrote:

> would appreciate you reviewing the usage in <https://datatracker.ietf.org/
> **doc/draft-douglass-timezone-**service/<https://datatracker.ietf.org/doc/draft-douglass-timezone-service/>>
> to make sure that looks right.
>
>
Yes, I'll do that shortly.

> syntax? It would be good to have something like that.

Not yet, but I'm looking into it.

-andy