Re: [Json] JSON Schema Language

[Anders Rundgren <[e-mail]>]

I believe I have stated my opinion but here it is again:

The idea is not changing JSON in any way but to add *strictness* to its interpretation.

This has ZERO impact on JSON parsers but could in some cases affect JSON serialization.

There are no problems defining a set of numeric types having a range and syntax that conforms to what is the norm for most programming languages since all of that fits nicely into JSON.

However, assuming that any JSON parser also could be used for *implementing* JSL (including verifying arbitrary input data) will set the bar way too low.

Regarding the integer discussion I believe Open API/Swagger which has quite an active and big user community already flags 3.0 as an invalid integer.  A bug report on Open API (or on Jackson) would most likely return "works as intended".

There's more, but I leave it there.

Anders



On 2019-05-08 01:57, Ulysse Carion wrote:
> Hi all,
> 
> I'd like to offer a summary of what has been stated thus far, so as to
> make a bit more sense of the conversation.
> 
> 1. Considerable ink has been spilled on the question of integers in a
> schema language. The main question has been how such an integral
> constraint should relate to serialization.
> 
> 2. Some have raised questions around the terseness of JSON Schema and
> JSON Schema Language. Proposed alternatives are JCR and CDDL, by their
> respective editors.
> 
> On the first question, I would agree with Messrs. Bormann and Bray,
> who both suggest that a generic JSON parser runs first, followed by a
> second pass over the data to convert the parsed data in the context of
> a schema. On such a view, "3" and "3.0" are typically
> indistinguishable by the time the schema is taken into account.
> Bormann aptly notes that the alternative runs the risk of de facto
> forking JSON itself. I don't think there is much more to be said on
> the matter.
> 
> The second question is perhaps more interesting, although it has
> provoked less discussion. I went with JSON as the representation
> because it makes building tooling atop of JSON Schema Language much
> easier, since it doesn't require that the implementor write a parser.
> Such ease of extension is valuable: JSON is widespread largely because
> of how easy it is to build atop of, and we should not readily
> sacrifice this. JSON as the representation also unlocks syntax
> highlighting, formatting, and other such niceties for free.
> Furthermore, and most importantly, using JSON as a representation does
> not preclude later creating a RELAX NG-style compact representation
> later on.
> 
> I would also like to echo Bray's point about the real-world utility of
> such a system. My day-job involves APIs, event-sourcing, and analytics
> messages. In all three, JSON is the lingua franca, and in all three
> considerable tedium is involved in writing and maintaining validators
> and language-idiomatic containers for JSON messages. No
> language-portable solution to this problem exists today, short of
> moving away from JSON toward something like Protobufs or CBOR.
> 
> I'd like to return to the initial question of this thread, this time rephrased:
> 
> Are we in agreement that the question of describing JSON, and from
> that description generating validators and idiomatic
> classes/types/etc, is a problem worth solving?
> 
> Are we in agreement that something along the lines of the proposed I-D
> may be a way we address this problem?
> 
> Best,
> Ulysse
> 
> On Tue, May 7, 2019 at 3:17 PM Nico Williams <[e-mail]> wrote:
>>
>> On Tue, May 07, 2019 at 02:56:10PM -0700, Erik Wilde wrote:
>>> On 2019-05-07 14:48, Phillip Hallam-Baker wrote:
>>>>      at the risk of referring to XSD too much, but i think they got it right:
>>>>
>>>>      - constraining facets for constraining the value space.
>>>>      - lexical facets for constraining the representation of values.
>>>>
>>>> I disagree on the constraining facets part. The only values I have found
>>>> useful to put in a schema are 0 or 1 minimum occurrences and 1 or
>>>> infinity maximum occurrences.
>>>
>>> there may be a misunderstanding here. constraining facets are limiting the
>>> value space of datatypes, for example by defining minimum and maximum
>>> values.
>>
>> As long as they don't constrain the encoding when multiple
>> representations are available.
>>
>> _______________________________________________
>> json mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/json