JSONSelect | Hacker News Reader

JSONSelect

jsonselect.org

I think I'm missing something here, because I can achieve the same using normal js

  stuff = {
    "author": {
      "name": {
        "first": "Lloyd",
        "last": "Hilaiel"
      },
      "drinkPref": [
        "whiskey",
        "beer",
        "wine"
      ],
    }, 
    "thing": "JSONSelect site",
    "license": "(cc) BY-SA"
  }

  stuff.author.drinkPref[0]
  > "whiskey"

Their site has a pretty bad example. Instead imagine it's an array of authors instead. Then their selector would give you a list of all their favourite drinks, which would require a loop in normal JS.

I think I'd prefer something more XPath-like than CSS myself (as someone linked in another comment)

I'd love to see a javascript+json version of xquery. It would rock as a templating language.

Naming it might be tricky though.

there is a minimal spec, and implementations, of JSONPath, which may be enough for you

Couldn't this be done with a simple map function? Not sure the exact javascript but in ruby it would be as simple as:

  favourite_drinks = authors.map { |a| a[:favourite_drink] }

Internally I'd imagine the language will have to loop through the json anyway. Are there any other benefits I'm missing (apart from of course the nice css-like syntax, which is perfectly valid).

It could be, yes. `map` isn't built-in on all browsers, though, which I think has hurt its use. i.e., most people don't think about it, so it doesn't get used as often.

Underscore.js and Prototype.js both define this function. You can include this and use map. Underscore delegates it to ECMAScript 5's native map if available.

It's definitely 'out there', and you can always just copy-paste to get the same code and delegation[1], but the lack of default availability is a pretty damaging blow. It shouldn't be, but the Javascript world isn't exactly a pantheon of high-quality code.

[1]: https://developer.mozilla.org/en/JavaScript/Reference/Global...

But selecting a list of similar items in plain JavaScript would be troublesome.

But what happens in the case where there is no author element?

With normal javascript you would get an exception .. hopefully with this you just get back undefined without having to check every step in the path.

with the reference implementation:

JSONSelect.match(".nonexistantkey .somechild", obj) returns []

Alternately, if you use the JSONSelect.forEach() method your callback will just not be invoked.

So no existence testing before access for recursive values. A main benefit of this thing in javascript.

That made me wonder if there is something that uses an XPath like approach rather than CSS selectors, turns out there is just such a thing:

http://goessner.net/articles/JsonPath/

These tools could be fun for writing map functions for CouchDB.

You might want to check out RQL, which builds on JsonPath:

  http://www.sitepen.com/blog/2010/11/02/resource-query-language-a-query-language-for-the-web-nosql/

My gut reaction is that 'feels like CSS' is not a selling point.

My prediction is that JSON will eventually reach feature parity with XML (this is quite similar to XPath), then we'll dump it for YAML or something.

Great.

JSON is almost the simplest untyped text-based tree serialization format that could possibly be designed. In terms of complexity, XML and YAML are closer together.

I'd argue that Lisp s-expressions are simpler.

S-expressions can contain code. Json expressions are data only.

It isn't that S-expressions can contain code, it's that they are so simple that based on a very simple syntactical rule set certain tokens can be interpreted as code or data and because of that you can easily "tokenize" pieces of "code" to make it "data" and vice versa (that's a really flexible feature). Kind of notable that S-expressions are an integral part of the language and not just a "data format" of the language...

You could easily invent a programming language expressed in JSON literals, it just wouldn't be quite the same as javascript. I'd argue that sexprs are simpler because they only use one container type (alists and plists are merely conventions, not baked into the grammar). However, JSON's omission of the symbol/string distinction is one argument the other way.

That might be a slightly amusing syntactical overlay on Common Lisp. Hash-tables are a bit manky to deal with directly IMO; setting up a reader macro in JSON-esque syntax might be quite usable.

Oddly enough, Steele pretty much already did this as a readtable example in his classic manual (based on xappings and xets from Connection Machine Lisp): http://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node192.html#X...

yeah, I noticed that as I worked on implementing the idea last night. :-)

Yes, you can, probably not too different in nature to Racket's syntactical sugar with using "[" (square brackets) to make reading the LISP code easier... And yes, your argument for their simplicity is actually what I was trying to express (much less successfully than you did).

True. I withdraw.

That S-expressions can/often contain code doesn't make them more complicated when used for data only. Anything can contain code.

A large amount of JSON is actually valid YAML.

I doubt it ever will. The reason why I use JSON is because it's a very simple data format; when I need more expressive and structured data interchange I always fallback on XML+XSD+XSLT - something JSON will probably never catch up with (because that already exists and why make JSON needlessly complex in order to handle what that kind of stack does?).

I think web developers get caught up in bashing XML a lot for no good reason - just because it isn't directly applicable to a simple RESTful API doesn't mean it isn't incredibly useful, it's meant for machines anyway!

XMLs great promise was that it was human readable. Lo and behold, it is more readable by non-bit-addled humans than whatever binary format is used in COBRA RPC.

But no, XML wasn't meant for machines... its just that people today programatically generate and consume XML far more often than they do it by hand.

I've been using jLinq - http://www.hugoware.net/Projects/jLinq

It would be great to see a standard emerge here. I've watched with interest as JSONPath and JSONQuery proposals have been presented, JS ports of Linq, and this latest proposal: RQL –

http://www.sitepen.com/blog/2010/11/02/resource-query-langua...

There's an Arel-style JS implementation to build RQL strings using chained methods, which makes it quite conducive to composition and makes it feel more like functional programming.

Along those lines are D3's selections:

  http://mbostock.github.com/d3/#selections

... and jLinq

  http://www.hugoware.net/Projects/jLinq

CSS is the worst. And this seems unnecessarily verbose: nth-child(1)

I'd imagine it wouldn't be hard to tweak the library to use "nc(1)" instead.

For "real" CSS in particular, I prefer a bit of verbosity over awk-like code. And you should likely be using a CSS generator anyway, it doesn't even have variables, for Knuth's sake :/

Please someone make this into a commandline utility that lets you pipe and query JSON around. My toolkit is missing a JSON slicer and splicer.

I thought "that would be interesting to build, I could call it jsawk" - turns out it exists already:

https://github.com/micha/jsawk

I hope to build jsonselect support on top of yajl and expose it as a native command line tool, so fast stream based filtering... but that's still ideaware at this moment :)

https://github.com/benbernard/RecordStream

As far as selectors go, it looks a lot better than JSONPath. I wonder how do they compare in speed.

Frankly it feels alot like LDAP.

Reply on news.ycombinator.com