Re: [Json] JSON Schema Language

[Tim Bray <[e-mail]>]

What do you mean by “Output specification”?

On Tue, May 28, 2019 at 8:01 PM Rob Sayre <[e-mail]> wrote:

> 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
>>
>