Re: [Json] JSON Schema Language

[Rob Sayre <[e-mail]>]

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