Re: Why is it "JSQuery"?

Oleg, Teodor, and Hackers:

Love what you’re doing with JSQuery. I’m curious, though, whether you considered adopting an existing syntax, such as JSONPath.

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

Might be easier for people to pick up and use. Thoughts?

Best,

David

On 06/05/2014 08:08 PM, David E. Wheeler wrote:
> Oleg, Teodor, and Hackers:
>
> Love what you’re doing with JSQuery. I’m curious, though, whether you considered adopting an existing syntax, such as JSONPath.
>
> http://goessner.net/articles/JsonPath/
>
> Might be easier for people to pick up and use. Thoughts?

My understanding is that it's meant to be analogous to tsquery.

At first glance, JsonPath doesn't seem to support AND and OR operators,
which would make it rather less expressive than I gather JSQuery is
meant to be.

cheers

andrew

On Jun 5, 2014, at 5:25 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:

> My understanding is that it's meant to be analogous to tsquery.
>
> At first glance, JsonPath doesn't seem to support AND and OR operators, which would make it rather less expressive than I gather JSQuery is meant to be.

Yes, but perhaps it could be a superset.

I guess my real question is: Should it not be based on some existing dialect, preferably something in fairly wide use outside the Postgres community?

Unless that something is awful, of course.

David

Jsquery - is QUERY language, JsonPath - is language to EXTRACT json parts.

On Fri, Jun 6, 2014 at 4:34 AM, David E. Wheeler <david(at)justatheory(dot)com> wrote:
> On Jun 5, 2014, at 5:25 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>
>> My understanding is that it's meant to be analogous to tsquery.
>>
>> At first glance, JsonPath doesn't seem to support AND and OR operators, which would make it rather less expressive than I gather JSQuery is meant to be.
>
> Yes, but perhaps it could be a superset.
>
> I guess my real question is: Should it not be based on some existing dialect, preferably something in fairly wide use outside the Postgres community?
>
> Unless that something is awful, of course.
>
> David
>

On Jun 6, 2014, at 6:54 AM, Oleg Bartunov <obartunov(at)gmail(dot)com> wrote:

> Jsquery - is QUERY language, JsonPath - is language to EXTRACT json parts.

Sure, but could we not potentially build on its syntax, instead of building a new one? I’m not saying we *should*, but if we don’t, I think there should be a discussion about why not. For example, I think it would not be a good idea to follow [JSONiq](http://www.jsoniq.org/) because who wants to write queries in JSON? (Have we learned nothing from XSLT?).

Here’s a (partial) list of existing JSON query languages:

http://stackoverflow.com/a/7812073/79202

The arguments might be:

* [JSONiq](http://jsoniq.org/): Queries in JSON? Gross!
* [UNQL](http://www.unqlspec.org/): Too similar to SQL
* [JAQL](https://code.google.com/p/jaql/): Too different from SQL
* [JSONPath](http://goessner.net/articles/JsonPath/): Too verbose
* [JSON Query](https://github.com/mmckegg/json-query): Too little there
* [Mongo](http://www.mongodb.org/display/DOCS/Inserting#Inserting-JSON): Gross syntax
* [LINQ](http://james.newtonking.com/archive/2008/03/02/json-net-2-0-beta-2): Too similar to SQL
* [searchjs](https://github.com/deitch/searchjs): Queries in JSON? Gross!
* [JQuery](http://jquery.org/): It's for HTML, not JSON
* [SpahQL](http://danski.github.io/spahql/): More like XPath
* [ObjectPath](http://adriank.github.io/ObjectPath/): Too verbose
* [JFunk](https://code.google.com/p/jfunk/): XPathy
* [JData](http://jaydata.org): Queries in JavaScript? C’mon.

These are just off-the-cuff evaluations in 10 minutes of looking -- surely not all of them are accurate. Some of them maybe *are* useful to emulate. It’s definitely worthwhile, IMHO, to evaluate prior art and decide what, if any of it, should inspire the JSQuery syntax, and there should be reasons why and why not.

I do think that the name should be changed if we don’t follow an existing standard, as [JSQuery](https://code.google.com/p/gwtquery/wiki/JsQuery) is already a thing.

Best,

David

On 06/06/2014 09:12 AM, David E. Wheeler wrote:
> On Jun 6, 2014, at 6:54 AM, Oleg Bartunov <obartunov(at)gmail(dot)com> wrote:
>
>> Jsquery - is QUERY language, JsonPath - is language to EXTRACT json parts.
>
> Sure, but could we not potentially build on its syntax, instead of building a new one? I’m not saying we *should*, but if we don’t, I think there should be a discussion about why not. For example, I think it would not be a good idea to follow [JSONiq](http://www.jsoniq.org/) because who wants to write queries in JSON? (Have we learned nothing from XSLT?).
>
> Here’s a (partial) list of existing JSON query languages:
>
> http://stackoverflow.com/a/7812073/79202
>
> The arguments might be:
>
> * [JSONiq](http://jsoniq.org/): Queries in JSON? Gross!

Also overly complex for the functionality we support. There's also no
way to make the jsquery strings valid JSON without adding a bunch of
extra text.

> * [UNQL](http://www.unqlspec.org/): Too similar to SQL

... also intended to be a *complete* replacement for SQL, whereas we
just want a syntax to search JSON fields.

> * [JAQL](https://code.google.com/p/jaql/): Too different from SQL
> * [JSONPath](http://goessner.net/articles/JsonPath/): Too verbose

I don't agree with the too verbose, but lacking AND|OR is pretty crippling.

> * [JSON Query](https://github.com/mmckegg/json-query): Too little there
> * [Mongo](http://www.mongodb.org/display/DOCS/Inserting#Inserting-JSON): Gross syntax
> * [LINQ](http://james.newtonking.com/archive/2008/03/02/json-net-2-0-beta-2): Too similar to SQL
> * [searchjs](https://github.com/deitch/searchjs): Queries in JSON? Gross!
> * [JQuery](http://jquery.org/): It's for HTML, not JSON
> * [SpahQL](http://danski.github.io/spahql/): More like XPath
> * [ObjectPath](http://adriank.github.io/ObjectPath/): Too verbose
> * [JFunk](https://code.google.com/p/jfunk/): XPathy
> * [JData](http://jaydata.org): Queries in JavaScript? C’mon.
>
> These are just off-the-cuff evaluations in 10 minutes of looking -- surely not all of them are accurate. Some of them maybe *are* useful to emulate. It’s definitely worthwhile, IMHO, to evaluate prior art and decide what, if any of it, should inspire the JSQuery syntax, and there should be reasons why and why not.

Well, I'd also say that we don't care about syntaxes which are not
already popular. There's no point in being compatible with something
nobody uses. How many of the above have any uptake?

Also, the explosion of query languages in this area is not an
encouraging sign for us being able to pick the "right" one. UUID-OSSP
anyone?

So the advantage of the current "jsquery" syntax is that it's similar to
tsquery, which already has some adoption in our userbase. On the other
hand, I'm not sure how many people actually understand the tsquery
syntax, and jsquery will be different enough to trip people up.

> I do think that the name should be changed if we don’t follow an existing standard, as [JSQuery](https://code.google.com/p/gwtquery/wiki/JsQuery) is already a thing.

I saw that too, but I don't get the impression that Google jsquery is
all that active. No?

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

On Jun 6, 2014, at 12:51 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:

>> * [JAQL](https://code.google.com/p/jaql/): Too different from SQL
>> * [JSONPath](http://goessner.net/articles/JsonPath/): Too verbose
>
> I don't agree with the too verbose, but lacking AND|OR is pretty crippling.

I had enough people complain about Test::XPath, which tests the structure of XML and HTML documents using XPath. They didn't like how verbose XPath was, preferring CSS selectors. So I ended up with a patch to support CSS syntax, too. CSS-style syntax is part of what people like about JQuery, too.

> Well, I'd also say that we don't care about syntaxes which are not
> already popular. There's no point in being compatible with something
> nobody uses. How many of the above have any uptake?

I think there is JQuery, JSONPath, and everything else, really. If we can draw some parallels, I think that would be sufficient to make people comfortable.

>> I do think that the name should be changed if we don’t follow an existing standard, as [JSQuery](https://code.google.com/p/gwtquery/wiki/JsQuery) is already a thing.
>
> I saw that too, but I don't get the impression that Google jsquery is
> all that active. No?

It’s Google. You really want to wrangle with their attorneys?

David

On 06/06/2014 03:23 PM, David E. Wheeler wrote:
> On Jun 6, 2014, at 12:51 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>> Well, I'd also say that we don't care about syntaxes which are not
>> already popular. There's no point in being compatible with something
>> nobody uses. How many of the above have any uptake?
>
> I think there is JQuery, JSONPath, and everything else, really. If we can draw some parallels, I think that would be sufficient to make people comfortable.

Well, then those are the only ones worth considering.

>>> I do think that the name should be changed if we don’t follow an existing standard, as [JSQuery](https://code.google.com/p/gwtquery/wiki/JsQuery) is already a thing.
>>
>> I saw that too, but I don't get the impression that Google jsquery is
>> all that active. No?
>
> It’s Google. You really want to wrangle with their attorneys?

Google is not going to sue us over a minor OSS project which isn't a
commercial product.

The relevant question is: are users liable to confuse our jsquery with
Google jsquery?

Maybe we should call it "jsonesque" ;-)

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

On Jun 6, 2014, at 3:50 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:

> Maybe we should call it "jsonesque" ;-)

I propose JOQL: JSON Object Query Language.

Best,

David

PS: JAQL sounds better, but [already exists](http://code.google.com/p/jaql/).

People,

we have many other tasks than guessing the language name.
jsquery is just an extension, which we invent to test our indexing
stuff. Eventually, it grew out. I think we'll think on better name
if developers agree to have it in core. For now, jsquery is good
enough to us.

jsquery name doesn't need to be used at all, by the way.

Oleg

On Tue, Jun 10, 2014 at 10:04 PM, David E. Wheeler
<david(at)justatheory(dot)com> wrote:
> On Jun 6, 2014, at 3:50 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>
>> Maybe we should call it "jsonesque" ;-)
>
> I propose JOQL: JSON Object Query Language.
>
> Best,
>
> David
>
> PS: JAQL sounds better, but [already exists](http://code.google.com/p/jaql/).

The closest problem we have is jsonb statistics (lack of, actually) ,
which prevents use of all the power of jsquery. I hope Jan Urbański
could work on this.

Oleg

On Tue, Jun 10, 2014 at 11:06 PM, Oleg Bartunov <obartunov(at)gmail(dot)com> wrote:
> People,
>
> we have many other tasks than guessing the language name.
> jsquery is just an extension, which we invent to test our indexing
> stuff. Eventually, it grew out. I think we'll think on better name
> if developers agree to have it in core. For now, jsquery is good
> enough to us.
>
> jsquery name doesn't need to be used at all, by the way.
>
> Oleg
>
> On Tue, Jun 10, 2014 at 10:04 PM, David E. Wheeler
> <david(at)justatheory(dot)com> wrote:
>> On Jun 6, 2014, at 3:50 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>>
>>> Maybe we should call it "jsonesque" ;-)
>>
>> I propose JOQL: JSON Object Query Language.
>>
>> Best,
>>
>> David
>>
>> PS: JAQL sounds better, but [already exists](http://code.google.com/p/jaql/).

On Jun 10, 2014, at 12:06 PM, Oleg Bartunov <obartunov(at)gmail(dot)com> wrote:

> we have many other tasks than guessing the language name.
> jsquery is just an extension, which we invent to test our indexing
> stuff. Eventually, it grew out. I think we'll think on better name
> if developers agree to have it in core. For now, jsquery is good
> enough to us.
>
> jsquery name doesn't need to be used at all, by the way.

Yeah, I was more on about syntax than the name. We can change that any time before you release it.

David

On 06/10/2014 02:46 PM, David E. Wheeler wrote:
> On Jun 10, 2014, at 12:06 PM, Oleg Bartunov <obartunov(at)gmail(dot)com> wrote:
>
>> we have many other tasks than guessing the language name.
>> jsquery is just an extension, which we invent to test our indexing
>> stuff. Eventually, it grew out. I think we'll think on better name
>> if developers agree to have it in core. For now, jsquery is good
>> enough to us.
>>
>> jsquery name doesn't need to be used at all, by the way.
>
> Yeah, I was more on about syntax than the name. We can change that any time before you release it.

I've been poking at the various json-query syntaxes you forwarded, and
none of them really work for the actual jsquery features. Also, the
existing syntax has the advantage of being *simple*, relatively
speaking, and reasonably similar to JSONPATH.

In other words, what I'm saying is: I don't think there's an existing,
poplular syntax we could reasonably use.

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

On 06/15/2014 04:58 PM, Josh Berkus wrote:
> I've been poking at the various json-query syntaxes you forwarded, and
> none of them really work for the actual jsquery features. Also, the
> existing syntax has the advantage of being *simple*, relatively
> speaking, and reasonably similar to JSONPATH.
>
> In other words, what I'm saying is: I don't think there's an existing,
> poplular syntax we could reasonably use.
>

Not to mention the similarity to tsquery, which is something not to be
despised.

cheers

andrew

On Jun 15, 2014, at 1:58 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:

> In other words, what I'm saying is: I don't think there's an existing,
> poplular syntax we could reasonably use.

Okay, I’m good with that. Would be handy to document it in such a way as to kind of put it forward as a standard. :-)

D