I agree... Who here has a use for this and/or JSONSchema (which I didn't know existed until today)? Javascript is a dynamic language, so why add this type of stuff onto it to make it more friendly to static languages.
If you're storing things so complicated that it needs to be validated in JSON format, perhaps you should choose a different serialization format.
I couldn't agree more, and will tell you that we're already there. I'm working on a project right now with an exceedingly complex JSON API. There isn't a day that goes by that I wish I could have gone back in time and had the team use XML instead.
It's definitely something I'm going to be looking at in the very near future. The pain we're experiencing is definitely worsened by the fact that it's largely undocumented internally as well.
Have you had experience with either technology, and if so, do you have a recommendation one way or the other?
Any time two different teams (or even people) are writing code that talk to common JSON, it's probably a good idea to define it in a schema. Think of it as a class of unit tests - except the relative effort required is miniscule, and the benefits exactly the same.
I can understand the desire to do define the formats, but this (Orderly) is bordering on ridiculous. You create a new microlanguage that compiles to a different microlanguage which is a DSL in the same language that your objects are stored in, so that it can be validated to be read properly in yet another language (unless your main code in already in Javascript). This just strikes me as a step down the path of WS-* or similar XML nonsense.
What ever happened to just having a README or documentation that just says what the fields in the object are? Why does it need to be validated by a different tool/language?
Sure you have a README and documentation. I once worked on a system which had a ProjectName-JSON-spec-verion-3.5a.doc of >200 pages being e-mailed back and forth between a "back-end team" in India, and a "front-end team" in New York.
That would basically be like writing another generator for the current orderly implementation. one capable of writing code. The thing would basically eat orderly_nodes and poop code.
Here's the intermediate representation of nodes that it could work from: