I see this is a Java library, but if you're in the command line (or even if you are able to call an external process for the job) jq[1] is great.<p>[1]: <a href="https://stedolan.github.io/jq/manual/" rel="nofollow">https://stedolan.github.io/jq/manual/</a>
The idea of supplying a spec to transform arbitrary data is interesting to me. I did one in JavaScript called Reshaper[1], and then hooked it up to a library wrapper called Smolder[2].<p>The result was a sort of system whereby data going into a function would be automatically 'reshaped'. It worked well as a proof-of-concept, but obviously was too fragile for most uses (though it's used in the automatic graphs in Kajero[3]).
The difference here seems to be that the spec defines the actual transformations, rather than just the desired final structure.<p>[1] <a href="https://github.com/joelotter/reshaper" rel="nofollow">https://github.com/joelotter/reshaper</a>
[2] <a href="https://github.com/joelotter/smolder" rel="nofollow">https://github.com/joelotter/smolder</a>
[3] <a href="https://github.com/joelotter/kajero" rel="nofollow">https://github.com/joelotter/kajero</a>
This seems like something that would lend itself to not tying itself to any specific implementation, yet it seems to be entirely based on a particular Java implementation.<p>It would probably be more useful if it more explicitly tied itself to the Java implementation (i.e. stop pretending to be its own thing) or were more abstract to be worth implementing in other languages.<p>In the latter case it'd be helpful if the operations were part of the actual unified DSL instead of having a DSL for each transformation (with the implication that each transformation is applied individually?).<p>EDIT: But if you abstract this away from Java, why not just use JSON Patch: <a href="https://tools.ietf.org/html/rfc6902" rel="nofollow">https://tools.ietf.org/html/rfc6902</a>
<i>sigh</i>, can we <i>please</i> just stop re-implementing S-expressions and Lisp, and instead just use S-expressions and Lisp?<p>It's like I'm the only one using electric lighting while all the hipsters are upgrading their wax-dipped hemp brands to artisan whale oil …
I've used template libs to do this in the past, e.g. mustache.js, handlebars.js, Jinja2, etc. Then generating JSON as output instead of HTML. Usually quick to learn the template libraries DSL, and I find templates easier to read than transforms.
Some food for thought:<p>JSON format+JSON.parse() make you loose the graph structure of the data you have on your server and that you send to the client.
Because it is basically a tree structure.<p>The Semantic Web defines a graph description langage called N3.
If your server can serialize and send the data in such a format, and if you use the function N3.parse() on your client, you eventually retrieve, on the client, a graph of in-memory objects that corresponds to the data graph on your server. You can then traverse that graph in any direction you want.<p>So basically, with N3, you never lose the graph structure of your data.<p>And you do not need to restructure your JSON.
In .Net-land, I've switched to doing this type of thing in Linq. But if you like XSLT (I still do), you can do it in three lines of code.
1. Convert JSON to XML
2. Run XSLT
3. Convert XML to JSON
Related/shameless plug: We've been working on a reimagining of JSONPath [1] which we hope will be useful to other people.<p>Unfortunately, it's not public yet — though we have working libraries in JavaScript and Go (a heavily modified fork of Kubernetes' JSONPath code) we intend to release — mostly because we want to publish a proper spec. In fact, we're looking for a good name for it, as we feel that releasing "JSONPath 2.0" would be a little presumptious. I was thinking something like JSONMatch. If there's sufficient interest I could prioritize it (email me!).<p>Our own version of JSONPath is intended for both searching and patching documents in general. A simple search would be something like:<p><pre><code> friends[name == 'bob'].id
</code></pre>
or<p><pre><code> shoppingItems[1:3][description, id]
</code></pre>
We use this to declaratively extract data from documents, but also change it. The patching support lets you do things like:<p><pre><code> match(document, "..[role == 'owner'].role")
.set('admin');
</code></pre>
This will set "role". It gets rather magical and beautiful when you have multiple paths that involve unions, subindexed arrays and constraints.<p>We also have a separate patch notation, expressed in JSON, to declaratively transform documents. It uses these JSONPaths to select and set values. We might write a spec for that, too, although I'm not sure the utility outside our app is that great.<p>[1] <a href="http://goessner.net/articles/JsonPath/" rel="nofollow">http://goessner.net/articles/JsonPath/</a>
The readme is more up-to-date than GitHub pages. It answers some of the questions in the comments. <a href="https://github.com/bazaarvoice/jolt" rel="nofollow">https://github.com/bazaarvoice/jolt</a>
This is an interesting take on schemas in json. Is the big advantage that this provides additional data validation (on top of type validation?) Can there be custom transforms written in javascript?
Well wy not go all the way there? It's just a matter of time. Here's the manual.<p><a href="http://www.wrox.com/WileyCDA/WroxTitle/XSLT-2-0-and-XPath-2-0-Programmer-s-Reference-4th-Edition.productCd-0470192747.html" rel="nofollow">http://www.wrox.com/WileyCDA/WroxTitle/XSLT-2-0-and-XPath-2-...</a>