Re: [Json] JSON Schema

[Henry Andrews <[e-mail]>]

Hi Tim,
  The current draft is draft-07 (although the actual IETF numbering is
complicated).  So draft-02 was a very long time ago :-)

You can find links to nice HTML renderings of all of the drafts, as well as
links to the official ietf.org hosted renderings, on our site at
http://json-schema.org/ (yes, we know we need to move to HTTPS, there's a
long difficult story there that is finally showing signs of resolution).
You will also find some guides to migrating to recent drafts and a bit of
explanation of the history, although we could use more/improved content on
those topics.  You will also find links to implementations, with notes
about which drafts are supported- draft-06 (April 2017) has been
implemented in several languages, and we're starting to see a few draft-07
(November 2017) implementations as well.

For discussions of improving or standardizing output (error or otherwise),
follow the "output" tag on the GitHub issues:
https://github.com/json-schema-org/json-schema-spec/issues?q=is%3Aissue+is%3Aopen+label%3Aoutput
While not an immediate focus, it is obviously on the list of concerns.  In
my view it is the responsibility of the spec to ensure that it is
*possible* to provide good output, but the fact that some implementation
fails to do so despite the possibility is not a reason to drop the spec.

Note that for the common complaint of difficult error messages with
"oneOf", we introduced "if"/"then"/"else" keywords in draft-07 (after
extensive debate as to whether they were "too imperative"- in the end the
community demand was extremely high, and the capabilities are no different
than with "oneOf", it's just easier to read and report errors with
"if"/"then"/"else" in many use cases).

thanks,
-henry


On Sat, Jan 20, 2018 at 1:49 PM, Tim Bray <[e-mail]> wrote:

> Could you give pointers to current drafts?  I had a horrible experience
> with JSON Schema (V2 I think? Whatever's current implemented) - the
> implementations were inconsistent with each other, the error messages out
> of the validators were simultaneously verbose and unhelpful, and I was
> looking at it trying to figure how I'd get better-quality messages, it
> seemed sort of intrinsically difficult. I would want to see existence proof
> of a validator that produced high-quality error messages before I could
> really get behind a design.
>
> I ended up writing my own schema language to produce a user-friendly
> validator, but it's on the eccentric side and I doubt of interest to the
> broader community: https://www.tbray.org/ongoing/When/201x/2016/12/
> 01/J2119-Validator
>
> Having said that, I think work on a schema language for JSON might be
> welcomed in the IETF, given a good draft to start with and an editor or
> editors who were interested in doing things the IETF way.  It's not that
> lightweight, we'd have to re-charter the working group, but far from
> impossible.
>
> On Sat, Jan 20, 2018 at 1:25 PM, Henry Andrews <[e-mail]>
> wrote:
>
>> Hi folks,
>>   I'm one of the JSON Schema draft editors, and it's been brought to our
>> attention that the JSON Schema project may fit within this working group
>> (or a successor?  I'm a little confused as to the current status and scope
>> of this group).  We are definitely interested in having the project adopted
>> by an IETF working group and eventually reaching RFC status if possible.
>>
>>   To date we have not felt like the project is quite ready for that step,
>> although I don't personally have a good feel for the criteria.  Since
>> October 2016, Austin Wright and I, with a great deal of behind-the-scenes
>> help from Ben Hutton and others, have published three drafts of JSON Schema
>> Core and Validation, four of Hyper-Schema, and two of Relative JSON
>> Pointer.  We are actively working on the next Core and Validation drafts
>> right now.
>>
>>   In addition to the obvious JSON Schema community engagement, we are
>> also working directly with the Open API technical steering committee to
>> resolve the problems that led them to adopt an
>> almost-but-not-quite-compatible form of JSON Schema.  I feel like they
>> are a good proxy for general adoption problems as they have a large
>> community of their own, and their concerns arise from common use cases that
>> are not quite well-served at this time (particularly code generation).
>> We've also engaged a bit with folks using JSON-LD who want to figure out
>> how to leverage both, although that idea is very embryonic at this time.
>>
>>   We're currently working on resolving some major questions of scope for
>> the project overall and the Core and Validation specifications in
>> particular (a lot of it related to how use cases such as code generation
>> fit with the existing targeted use cases).  I hope to resolve these in the
>> next major draft before the current ones expire.  There may be a minor
>> bug-fix in the next week or so, separate from that effort, and one
>> additional scope question may be deferred to another draft beyond that.
>>
>>   Once the scope is settled, I had planned to actively look into working
>> group status for the core and validation specifications.  Hyper-Schema
>> requires more work and at least a few viable implementations.  Relative
>> JSON Pointer could probably move to working group status as well if it is
>> of interest (we've also considered merging it into JSON Schema Core if
>> there is no interest in it as its own RFC: JSON Path is not a good fit for
>> our needs despite being a great idea in its own right, and we already make
>> extensive use of JSON Pointer).
>>
>>   I believe that the ongoing broad use and implementation of JSON Schema
>> despite a multi-year abandonment of the draft work shows that it is a very
>> viable and useful technology despite the complaints around the edges (I
>> noticed that the complaint on this mailing list from 2016 was also about
>> code generation- as I mentioned, that's a current focus of ours to
>> resolve).  We've started to see implementations of the new drafts in use,
>> and interest in the latest draft picked up even more quickly than the one
>> before, so there seems to be real interest in taking JSON Schema over the
>> finish line into some sort of official standard. The current team is
>> committed to seeing this through. The recent change in submitting editor is
>> just a reflection of who had the most time; the core team members have all
>> remained involved since draft publication resumed.
>>
>>   I'm interested in any feedback or suggestions on the path forward.
>>
>> thanks,
>> -henry
>>
>> --
>>
>>    -
>>
>>    *Henry Andrews*  |  Systems Engineer
>>    [e-mail]
>>    <https://www.cloudflare.com/>
>>
>>    1 888 99 FLARE  |  www.cloudflare.com
>>    -
>>
>>
>> _______________________________________________
>> json mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/json
>>
>>
>
>
> --
> - Tim Bray (If you’d like to send me a private message, see
> https://keybase.io/timbray)
>



-- 

   -

   *Henry Andrews*  |  Systems Engineer
   [e-mail]
   <https://www.cloudflare.com/>

   1 888 99 FLARE  |  www.cloudflare.com
   -