Subject: [Jsonpath] Title of the specification

From: Carsten Bormann <[email-masked]>
Date: Thu, 26 Nov 2020 17:03:04 +0100

The draft at https://github.com/jsonpath-standard/internet-draft currently uses the title:

JavaScript Object Notation (JSON) Path

The draft at https://github.com/jsonpath-wg/draft-goessner-jsonpath uses:

JSONPath — XPath for JSON

I think we have discussed here that we don’t want to emphasize XPath in the title any more.

The former title evokes JavaScript in a needless attempt to expand the JSON acronym.  The RFC editor has decided that this is not needed for JSON (see the “*” in [1]); I believe that this expansion is detrimental as JSONPath is neither limited to nor even focused on JavaScript.

So this would turn it into 

JSON Path

which we don’t like, so it becomes

JSONPath

which is a bit terse.

So I’d propose to add the purpose in the title:

JSONPath: A query language for JSON values

or maybe a bit more understandable:

JSONPath: A query language for JSON data values

We can also discuss “language”, which I’m happy with, but might trigger associations with long-form languages (COBOL…).  Hmm.  Maybe:

JSONPath: A concise query language for JSON data values

(Use title case here, of course, I’ll leave that to the natives.)

Grüße, Carsten

[1]: https://www.rfc-editor.org/materials/abbrev.expansion.txt

---

From: Alan Painter <[email-masked]>
Date: Thu, 26 Nov 2020 17:31:07 +0100

Just a few off-the-cuff thoughts:

a.  Is there any distinction between "JSON data" and "JSON" itself?  Could
this be simply "A language for querying JSON" ?
b.  Does "concise" add anything?  Makes the title less concise.

On Thu, Nov 26, 2020, 17:03 Carsten Bormann <[email-masked]> wrote:

> The former title evokes JavaScript in a needless attempt to expand the
> JSON acronym.  The RFC editor has decided that this is not needed for JSON
> (see the “*” in [1]); I believe that this expansion is detrimental as
> JSONPath is neither limited to nor even focused on JavaScript.
>
> We can also discuss “language”, which I’m happy with, but might trigger
> associations with long-form languages (COBOL…).  Hmm.  Maybe:
>
> --
> Jsonpath mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jsonpath
>

---

From: Glyn Normington <[email-masked]>
Date: Thu, 26 Nov 2020 16:40:33 +0000

> On 26 Nov 2020, at 16:31, Alan Painter <[email-masked]> wrote:
> 
> a.  Is there any distinction between "JSON data" and "JSON" itself?

Yes, I believe so. The former refers to a piece of data, but the latter refers to a notation. The distinction is significant when we want to be precise.

> Could this be simply "A language for querying JSON" ?

I think that's fine in the title where concision trumps precision.

> On Thu, Nov 26, 2020, 17:03 Carsten Bormann <[email-masked] <mailto:[email-masked]>> wrote:
> The draft at https://github.com/jsonpath-standard/internet-draft <https://github.com/jsonpath-standard/internet-draft> currently uses the title:
> 
> The draft at https://github.com/jsonpath-wg/draft-goessner-jsonpath <https://github.com/jsonpath-wg/draft-goessner-jsonpath> uses:
> 
> [1]: https://www.rfc-editor.org/materials/abbrev.expansion.txt <https://www.rfc-editor.org/materials/abbrev.expansion.txt>
> 
> -- 
> Jsonpath mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/jsonpath <https://www.ietf.org/mailman/listinfo/jsonpath>
> -- 
> Jsonpath mailing list
> [email-masked]

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 26 Nov 2020 17:50:09 +0100

> On 2020-11-26, at 17:40, Glyn Normington <[email-masked]> wrote:
> 
> 

Well, the title needs to be useful for a much wider audience than the rest of the document.  This is the first step for someone to decide whether to go on reading the abstract and then the document.

For most of us here “JSON” is acceptable vernacular for “JSON data item”.
“Give me a JSON for that.”, hmm.
But for many people that use JSON only packaged into some products, that would be weird.

I think that expressing that we are reaching into those data values is worth adding a word or two.

If pointing out the conciseness is less important than conciseness of the title, I would probably compromise at

JSONPath: A query language for JSON data

(The “values” addition really doesn’t add much.)

(I’m also assuming we keep the studlycaps, as XPath did.)

Grüße, Carsten

---

From: Glyn Normington <[email-masked]>
Date: Thu, 26 Nov 2020 16:52:40 +0000

> On 26 Nov 2020, at 16:50, Carsten Bormann <[email-masked]> wrote:
> 
> 
> 

+1

---

From: Tim Bray <[email-masked]>
Date: Thu, 26 Nov 2020 09:05:55 -0800

I think I’d slightly prefer the term “syntax” to “language” because “query
language” has a smell of various things that end with the letters “Q” and
“L”.  But not passionate about that.

I am pretty sure that it should end with just “JSON”.  In practice, people
who write JSONPath expressions really don’t care what, under the covers,
the form of JSON is that it’s being applied to.  They probably look at an
example of the input JSON text and while we all know it has to be parsed
into some in-memory representation to apply a JSONPath, that's just
book-keeping.

So my favorite would be "JSONPath: A query syntax for JSON” I’m also OK
with “language”

Another wild-card idea: JSONPath: Query expressions for jSON

On Thu, Nov 26, 2020 at 8:52 AM Glyn Normington <
[email-masked]> wrote:

> Yes, I believe so. The former refers to a piece of data, but the latter
> refers to a notation. The distinction is significant when we want to be
> precise.
>
> Well, the title needs to be useful for a much wider audience than the rest
> of the document.  This is the first step for someone to decide whether to
> go on reading the abstract and then the document.
>

---

From: Alan Painter <[email-masked]>
Date: Thu, 26 Nov 2020 18:10:20 +0100

+1 for "JSON" sans the "data" qualifier

On Thu, Nov 26, 2020 at 6:06 PM Tim Bray <[email-masked]> wrote:

>> Well, the title needs to be useful for a much wider audience than the
>> rest of the document.  This is the first step for someone to decide whether
>> to go on reading the abstract and then the document.
>>

---

From: Glyn Normington <[email-masked]>
Date: Thu, 26 Nov 2020 17:10:54 +0000

> On 26 Nov 2020, at 17:05, Tim Bray <[email-masked]> wrote:
> 
> I think I’d slightly prefer the term “syntax” to “language” because “query language” has a smell of various things that end with the letters “Q” and “L”.  But not passionate about that.  
> 
> I am pretty sure that it should end with just “JSON”.  In practice, people who write JSONPath expressions really don’t care what, under the covers, the form of JSON is that it’s being applied to.  They probably look at an example of the input JSON text and while we all know it has to be parsed into some in-memory representation to apply a JSONPath, that's just book-keeping. 
> 
> So my favorite would be "JSONPath: A query syntax for JSON” I’m also OK with “language”

One downside of syntax is that it might give the impression of “but not semantics”. But I don’t feel strongly.

> Another wild-card idea: JSONPath: Query expressions for jSON

I quite like that.

> 
> On Thu, Nov 26, 2020 at 8:52 AM Glyn Normington <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>> On 26 Nov 2020, at 16:50, Carsten Bormann <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> 
>>> On 2020-11-26, at 17:40, Glyn Normington <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> 
>>>> On 26 Nov 2020, at 16:31, Alan Painter <[email-masked] <mailto:[email-masked]>> wrote:
>>>>

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 26 Nov 2020 20:43:04 +0100

>> Another wild-card idea: JSONPath: Query expressions for jSON

Works for me!
(With an all-caps “JSON”).

Grüße, Carsten

---

From: Marko Mikulicic <[email-masked]>
Date: Thu, 26 Nov 2020 23:23:16 +0100

I don't see anything wrong with calling it a "query language". It's a
language. It performs queries.

An "expression" commonly means a part of a language that evaluates to a
value (e.g. as opposed to a statement). We could say "expression language",
but it may be unnecessary in the title and potentially misleading since
many expression languages out there can produce new values (e.g. jq) while
JSONPath selects matching elements from an input set, which puts it
squarely in the realm of query languages.

Not sure what's exactly the danger of associating by lexical proximity with
the other *QL beasts. Could you please elaborate on that?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 27 Nov 2020 03:18:33 -0800

> “L”.  But not passionate about that.

I was going to say this too.  Or perhaps "grammar".

-MSK

---

From: Michael Kay <[email-masked]>
Date: Fri, 27 Nov 2020 11:38:21 +0000

Perhaps

JSONPath -- A Selector Language for JSON

("CSS Selectors" are universally referred to as "CSS Selectors", though the title of the W3C Recommendation is simply "Selectors", probably because the WG had grander ambitions for them and didn't want to limit the scope. I suggest the term here because it has connotations suggesting a fairly small expression language, and will be familiar in the target user community.)

Michael Kay

> On 27 Nov 2020, at 11:18, Murray S. Kucherawy <[email-masked]> wrote:
> 
> On Thu, Nov 26, 2020 at 9:06 AM Tim Bray <[email-masked] <mailto:[email-masked]>> wrote:

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 27 Nov 2020 13:55:37 +0100

> Another wild-card idea: JSONPath: Query expressions for jSON

The beauty of this is that the plural form “query expressions” implies a set of expressions, so it implies “language”.  It’s indeed more than the grammar/syntax of those, so why not talk about the expressions as a whole.  This also makes it possible to just use “for JSON”, without going into detail what these query expressions operate on.

> On 2020-11-26, at 23:23, Marko Mikulicic <[email-masked]> wrote:
> 
> An "expression" commonly means a part of a language that evaluates to a value (e.g. as opposed to a statement).

In programming languages maybe.  This says “query expressions”.
(See the first entry on https://en.wikipedia.org/wiki/Expression:
»Expression (linguistics), a textual unit (commonly known as sentence)«, and it goes on for six more before coming to the programming language idiom, and then goes on to regular expression.)

Grüße, Carsten