Re: [Json] JSON Schema Language

[Carsten Bormann <[e-mail]>]

On May 10, 2019, at 05:55, Ulysse Carion <[e-mail]> wrote:
> 
> Carsten,
> 
> Do you think that our difference in opinion on CDDL vs JSON Schema
> Language may be attributable to a difference in requirements?

Hi Ulysse,

I’m not even sure we disagree.  That was why I became interested in converting between JSL and CDDL.  As I was trying to show, CDDL might make a fine presentation language for JSL, and JSL might be a nice “profile” for CDDL that is very simple to process.

> It seems to me that your use-case is centered around defining
> standards and other complex data requirements. CDDL is, in my view,
> unquestionably a better choice for this use-case. In my mind, CDDL is
> ABNF for CBOR, and that is undeniably what standards dealing with CBOR
> or its near-equivalents require. The existing references, from RFCs,
> to CDDL are testament to this.

Yes, you are describing the intention correctly.  I would add that CDDL has proven as useful for describing pure JSON protocols as for CBOR.  

Not all JSON/CBOR protocols need the full capabilities of CDDL.  For instance, the example in the CDDL spec for RFC 7071 could easily be expressed in JSL, except for two details: reputation-object is not meant to be extensible (reputon is), and there are some value constraints (some values are integers).

> But I (and I suspect Tim) am more preoccupied solely with defining the
> mundane sorts of messages that come out of JSON event processing and
> repetitive JSON APIs. Tim has blogged (see link in my original email)
> about dealing with AWS's CloudWatch events. That's messages that look
> like this:
> 
> https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/EventTypes.html
> 
> Tons of messages, and frequently being added and updated. But none of
> these messages are particularly exciting from a schema perspective.

Well, I just had a look at (randomly selected)
https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/EventTypes.html#health-event-types
You’d need to add enumerations to JSL.  There are also timestamps in the object (ironically in two different formats).  There is a table that maps language tags to messages in that language.  (And the second and third example have a missing bracket.)  But I can’t really say, because the description by example only just begins to expose the actual intention.

> CDDL can do much more than is necessary for merely representing
> CloudWatch events. This may seem like a good thing, but such excess
> capability reduces the suitability of the solution. JSON Schema
> Language is intentionally small and scuttled in scope, so as to
> simplify code and UI generation. By being so limited in scope, JSON
> Schema Language fits more easily into the architecture of a system
> that would like to integrate it.

I’ve seen my share of developments that start simple.  How much functionality will be added to JSL before it becomes a standard?  Also, the law of extensibility tells us it will be extended even after becoming a standard.

Of course, in its domain, CDDL is incredibly simple.  Compare to JCR: JCR is about three times as complex as CDDL.  This is because CDDL was built from a few very simple building blocks, which combine nicely to provide its functionality.  JCR is more of an accretion of features, which in sum can do most of what CDDL can do.

But back to JSL and CDDL:
What I’m interested in is what are the sweet spots on this functionality vs. complexity continuum.  I think we have found two of these sweet spots (at least maybe after a little more calibration).  Now how do we handle the onslaught of applications that don’t quite fit the sweet spots?  

The question that intrigues me: Is it possible to define something that is as simple as JSL when you need just that, but allows dipping into the capabilities of something like CDDL where needed?

By the way: You may not be aware of the WISHI activity we have in the T2TRG (thing-to-thing research group) of the IRTF.  Here we look at modeling (not just for data) and at translating between different modeling approaches.  http://wishi.space if you want to have a look.

Grüße, Carsten