Re: [Json] JSON Schema Language

[Rob Sayre <[e-mail]>]

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

> TBH, what I want from a schema system is (a) useful error messages and (b)
> ability to drive code generation, classes and serializer/deserializers and
> so on.
>

No problem. If it can drive serializer/deserializers, let's spec out some
conformance tests.

- Rob


> On Tue, May 28, 2019 at 8:40 PM Rob Sayre <[e-mail]> wrote:
>
>> On Tue, May 28, 2019 at 8:23 PM Tim Bray <[e-mail]> wrote:
>>
>>> What do you mean by “Output specification”?
>>>
>>
>> Fair question. I'd say a good example might be the objects transferable
>> across postMessage() in browser JavaScript.
>>
>>
>> https://html.spec.whatwg.org/multipage/structured-data.html#transferable-objects
>>
>> It seems like a deep problem at first, but it isn't. Those message
>> formats add Date objects and a few other things, but not that much.
>>
>> - Rob
>>
>>
>>
>>
>>
>>> 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
>>>>>
>>>>