
JSONSelect - creativityhurts
http://jsonselect.org/#overview
======
cubicle67
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"

~~~
kalleboo
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)

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

Naming it might be tricky though.

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

------
arethuza
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.

~~~
audionerd
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/

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

------
zdw
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.

~~~
wvenable
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.

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

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

~~~
Ixiaus
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...

~~~
prodigal_erik
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.

~~~
pnathan
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.

~~~
prodigal_erik
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...](http://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node192.html#XAPPINGMACROCHARTABLE)

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

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

------
audionerd
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...](http://www.sitepen.com/blog/2010/11/02/resource-query-language-a-
query-language-for-the-web-nosql/)

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

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

~~~
Groxx
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 :/

------
mhansen
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.

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

<https://github.com/micha/jsawk>

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

------
perlpimp
Frankly it feels alot like LDAP.

