Re: [Json] JSON Schema Language

[Tim Bray <[e-mail]>]

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.

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