Reminds me of XSD - the XML schema definition language that itself is XML. Any takeaways (good/bad/ugly) from that experience that are applicable here?
I personally think it's great. The faster the ecosystem is reinvented the sooner we can stop wasting our lives reading it.
JSON-schema solves many of the validation issues of JSON in the absence of an XSD-for-JSON solution, to allow message processing and other validation assertions. From that perspective it's 'duplicated effort', but only to the extent that JSON messaging applications are maturing to the point they need the kinds of guarantees that were so clear during the development of XML/SGML. It's a whole different language supporting a range of JSON-powered clients that don't necessarily require transformation support or other guarantees.
This is about JSONs ecosystem maturing to the baseline, not about reinventing the wheel :)
This just serves to provide a way to say "yes, we can have strongly typed schemas as well as our nice succinct format" to those who need it.
Generate useful docs. Easy to read to get a handle on data structure. Also can be used as runtime contracts. somewhat similar but v. limited compared to Racket Contracts and Clojure spec.
Not to mention super tooling for interacting with schema (like XMLSpy)
In conclusion, having schemas for data structures(especially at boundaries) is absolutely necessary to maintain control & visibility over data.
Data schemas are the first step in powering transformations, which is where most of the Enterprise is bound up.