relequestual

The JSON Schema community would LOVE some more detailed feedback on this. We would ideally like to do that in our slack or via a GitHub Discussion. Can you reach either of those OK? Please ping/mention me, same username.

The team at JSON Schema finally got access to deeper network traffic analytics via CloudFlare. We knew there were lots of requests being made, but details were limited. We dive into the data and make some interesting discoveries.

We (JSON Schema) did a case study/interview with the guy behind it https://www.youtube.com/watch?v=-yYTxLZZk58&list=PLHVhS4Tj1Y...

Here's a YouTube playlist of 6 case studies with companies of various sizes: https://www.youtube.com/watch?v=fkziMQD7pqQ&list=PLHVhS4Tj1Y...

There are also two written case studies on the JSON Schema blog: https://json-schema.org/blog/

It is not =]

Additionally, the value is a "schema" as opposed to a boolean, meaning you can apply a subschema to any additional fields. Useful if you for instance want to make sure any additional fields start with a specific prefix.

Booleans are valid schemas. It's subschemas all the way down! I wrote an article around this topic: https://json-schema.org/blog/posts/applicability-json-schema...

Part of the problem is they wrote that site and its content for a specific version of JSON Schema. The `items` keyword no longer takes an array form value in the latest version of the specification, while their documentation shows that it does.

I seem to recall other issues, but can't find them now. We may have raised issues which were resolved, but I don't recall the specifics.

Actually, currently, this is not the case. The specification explicitly allows for additional fields for the purposes of extensions. We are considering changing that, and only allowing pre-defined fields, or having a way to mark specific fields as limited extensions.

A project exists which does this, and the team even support its development: https://github.com/sourcemeta/alterschema

Personally, I'd like to see it become officially supported. We have work to do!

Thanks for sharing. This is useful commentary to see. We try to be helpful to maintainers. If any have questions, the JSON Schema server has an implementers channel! We would like to be able to support implementers financially, but we need other companies to add their support in order to do that. And for that, we need to better communicate our value proposition. We're working on it!

The OP actually created a tool that allows you to upgrade your schemas between versions of JSON Schema. It's pretty neat, and has had the eyes of those who write the spec. https://github.com/sourcemeta/alterschema

And this is exactly why we are asking this sort of question. This sort of feedback is useful. Thanks. Some of the people working on the spec have had a similar idea and it may end up being part of the spec.

Watch out for that second link. Not everything there is accurate. If you or anyone has suggestions to improve the docs (first link), filing issues or PRs are more than welcome!

Could you elaborate where you see the namespacing?

This is correct.

If I had used a more complex example, it would have been much harder to follow. This was the simplest.

We factor this out for our meta-schema construction due to reuse.

Do you mean the article or the specification?

Expectation of a single schema by existing tooling.

If only they had used used the official test suite... which is provided, free of charge, in JSON.

We really just wanted to signal that people shouldn't expect any attention on issues or PRs raised against Hyperschema till we can make time for it. Spec work is hard ya'll

Hi all! I'm one of the new team that works on JSON Schema since draft-4.

I could spend time addressing each issue raised here, but that could take some time...

@niftich We've (the new authorship) actually been working on JSON Schema since late 2014!

If you're using JSON Schema, or are interetested in finding out more, we DO now have a slack server; invite link at the bottom of json-schema.org. Come talk with us.

We're looking for companies who are using it in production to weigh in on new developments and releases. Our current release plan means we will have an RC with time for feedback. We want to hear your issues, comments, and suggestions!

One common problem at current is the level of support. Because draf-4 has been around for a LONG time now, it became the defacto standard, and has the most support. Developers come along and use an older library which only supports draft-4, but want to use new functionaltiy found in draft-7. Many implementations support draft-7, and some even implement new functionaltiy before it's finalised. SO remember to check which version of JSON Schema the library you're using supports.

HyperSchema already exsisted at that point, so we inheirted it. It focuses on providing specification for correct HTTP usage and HATEOAS driven APIs, where as other higher level API specification languages allow you to describe any type of API.

It looks like a good number of you have good questions, ideas, or issues. Thanks for all those replying supporting JSON Schema and those showing a balanced viewpoint.

Come chat with us!

I remember during my degree, we were literally told to copy paste some javascript and change few variables. That was it for javascript... If it wasn't for SO, I would never have got the placement I did, nor understood the concepts I do now.