Re: [Json] JSON Schema Language

[Tim Bray <[e-mail]>]

So Carsten, I am a person who would benefit from a super-simple JSON schema
langauge; in effect, something like JSL + enums + timestamps.  Furthermore,
as I've said, I'm willing to invest some IETF-work cycles to get such a
thing, in the event we could interest the community.  Do you think that
doing such a JSL and defining it using established CDDL semantics might be
a good idea?

Alternately, might we retain CDDL syntax and define a profile/subset which
would be appropriate for us JSON-only simpletons?

I'm not terribly fussy about mechanisms.



On Fri, May 10, 2019 at 12:16 AM Carsten Bormann <[e-mail]> wrote:

> 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
>
> _______________________________________________
> json mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/json
>