I like JSON schema, but I haven't found any good tools to designing them. Or at least not a few years ago when I was looking.
However, we already had an XMLSpy license, so decided to just stick with designing XSDs in XMLSpy and then just translate that to JSON Schema.
If you make some small decisions, like value with attributes becomes an object, you can get a fairy decent subset of XSD to map 1:1 onto JSON Schema 2020-12.
As a nice side effect of writing the XSD to JSON Schema converter, it's trivial for us to support reading XMLs and convert that to JSON. Great for the customers who have programs that doesn't speak JSON.
Yes, I've been searching for a long time for a good solution to allow non-coding people to visually design JSON Schemas. The closest thing I found is the schema editor in the amazing Stoplight service, but that is sadly not open source.
Heck, I'm a coder and I get lost when just dealing with the raw JSON Schema.
It's not a problem for a dozen properties, but we have several hundreds in our larger schemas, even accounting for them being fairly normalized w.r.t. types. And five or more levels of nesting turns into an effective ten plus levels in the schema.
One underutilised feature of JSON Schema is referencing external schemas and reusing them in multiple places, rather than copying them over and over again. The main hurdle to a better use of this feature is the lack of a good standard for schema repositories; I've been working on addressing this, but it's difficult to find the time. :/
> One underutilised feature of JSON Schema is referencing external schemas and reusing them in multiple places
Yeah, though while it does make each subschema somewhat more readable and contained, you still don't get a good overview. If you're reading the spec for a given object, do you don't easily see where it's being used in the schema.
For now I've just supplied the JSON Schema as a self-contained thing, and deferred other parties to the XSD to get an overview. The self-contained makes it trivial to load into a validator and such.
So while it helps for knowing what to fill into that exact object, it doesn't help for getting a feel for the overall schema. This is where the visual view of tools such as XMLSpy really helps.
> lack of a good standard for schema repositories
Interesting, do you have something public to show? For our large ones I feel they'd be entirely custom anyway, but perhaps I can see standard sub-schemas useful for other tasks. Would be interesting to have a look.
True, when focusing only on the schemas as code. But good tooling could provide links and similar.
> do you have something public to show
Just a very early PoC [0]. I'm slowly working my way through a very long to-do list of improvements, but I'm lacking time and resources to do it more efficiently.
However, we already had an XMLSpy license, so decided to just stick with designing XSDs in XMLSpy and then just translate that to JSON Schema.
If you make some small decisions, like value with attributes becomes an object, you can get a fairy decent subset of XSD to map 1:1 onto JSON Schema 2020-12.
As a nice side effect of writing the XSD to JSON Schema converter, it's trivial for us to support reading XMLs and convert that to JSON. Great for the customers who have programs that doesn't speak JSON.