Hacker News new | ask | show | jobs
by peterkelly 2146 days ago
They made the same poor choice as the designers of XML schema, which is to use the target language itself to describe the schemas. That is, a JSON Schema is written in JSON. As a result, they're extremely verbose and tedious to work with.

If you contrast JSON Schema with the type declaration subset of TypeScript, you'll find that the latter is much more concise and readable.

Having said that, there's an interesting discussion to be had about the distinction (if any) between schemas as understood in the database/XML/JSON world and types used in programming languages. JSON Schema does more than most programming language type systems do (e.g. requiring string lengths/numbers be within a certain range) and this is useful for validation. It still doesn't excuse the syntax though.

4 comments

The advantage is that you don't need to have another parser at the ready to parse your schema definition.
You can also more easily generate schemas, or generate things from schemas, if they're in JSON.

Sure, you can still do these things when schemas are a non-JSON format, but it increases the barrier of entry to writing tooling on top of schemas.

It's technically possible to devise an alternative syntax and a bidirectional converter between it and the json jsonschema syntax. potentially the current json syntax could become some sort of "intermediate representation" not meant for direct human consumption but still useful to simplify implementation of tools that generate or interpret schemas (which wouldn't need a full fledged parser)

A quick web search didn't yield any existing project attempting to do so, but perhaps I'm not typing the right keywords. Does anybody know if this exists?

If not, would you like it? What would be the main characteristics such a syntax should have? (Mine pet peeve are comments, i.e. lack thereof in json)

I am building one, but it just started. Turns out we can even implement module system on json scchema. It's going to be convention/opinion based output; a subset of how a thing is described in jsonschema e.g. tagged union.

Jsonschema is a mixed bag of structure and validation, that sounds simplified, but its expressive power comes from the mix. For example, I have to limit the use of "Applicator" keyword (oneOf, allOf, anyOf) only under my controlled keywords under $defs .. urggg.

I hope in 2-3 months I could get a beta out.

I think there's an argument to be made that validation should be done with a turing complete language to be most effective. However, JSON schema, while weaker and more verbose does have the advantage of programming language independence which whatever typescript has absolutely does not.

Either way JSON schema is fairly lightweight and didn't try to accidentally create an awful new programming language (cough XSLT cough). I don't see it as indicative of any of the kind of fuck ups XML went through.

It was a great choice for XML... I've used XSLT to transform schemas into code many times.... (related: XSLT is more readable than JSON equivalent 'jq')