Re: [Json] JSON Schema Language

[Rob Sayre <[e-mail]>]

I'm not sure this schema language will be productive as a source format in
the long term, but I don't think it will be harmful. So, it's not worth an
objection. The worst case would be that servers claim to conform to this
schema language, but fail to serve schema-conformant JSON in practice. This
seems like the likely outcome, in the absence of an output specification.

I have to say, I think I am uniquely qualified to raise this point. I
objected to the original JSON Stringify specification, which was something
pretty close to string concatenation, and got it corrected to something
close to its current form.

If a schema language doesn't provide an output specification, it's probably
not going to work in practice. Best case, it's a standards checkbox.

- Rob


On Tue, May 28, 2019 at 7:41 PM Tim Bray <[e-mail]> wrote:

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