Subject: [Jsonpath] truthy and falsy

From: Glyn Normington <[email-masked]>
Date: Wed, 8 Sep 2021 12:12:41 +0100

The terms "truthy" and "falsy" are used in the current draft, but are not
defined. Please could someone provide a (pointer to a) good definition?

Regards,
Glyn

---

From: Daniel P <[email-masked]>
Date: Mon, 13 Sep 2021 13:33:43 -0400

On Fri, Sep 10, 2021 at 6:38 AM Stefan Gössner <[email-masked]> wrote:
>
> The latest draft is quite clear:
>
> > The query is a sequence of zero or more selectors, each of which is applied to the result of the previous selector and provides input to the next selector. These results and inputs take the form of a nodelist, i.e., a sequence of zero or more nodes.
>
Yes, but by query you're referring to grammatical strings that start
with '$'. I was responding in context to grammatical strings that
start with '@' in expressions, e.g. $[?(@.name)].

In terms of the current JSON landscape, do strings that start with '@'
represent JSONPath expressions in the same way as strings that start
with '$'? And evaluated accordingly? Or do they correspond to a
Javascript (or another dynamic language) variable, holding an object,
array, string, number, boolean, or null value, and evaluated according
to the rules of that language?

It depends upon what implementation you look at.

At least 12 (probably more) implementations in the JSONPath
Comparisons regard strings that start with '@' to be JSONPath
expressions. Of these, 12 also accept strings starting with '@'
outside expressions in place of '$', e.g. "@.foo", to do otherwise
would only complicate their grammar. These include the Java Jayway
implementation, which is part of the bedrock of JSONPath, deeply
embedded in legacy Java API's.

But in the implementations that use a dynamic language for evaluating
queries, such as Goessner Javascript, strings that start with '@'
don't mean JSONPath expressions at all. In these languages, '@' means
a variable holding an object, array, string, number, boolean, or null
value as represented in that language, and nothing more. There are no
"nodelists", however understood, here. These implementations do not
accept strings starting with '@' outside expressions in place of '$',
as it would serve no purpose.

I realize the WG draft hasn't completed its specification for
expressions yet. But as I read the draft, it seems to me to be
specifying the grammar and semantics for expressions, like the first
group of implementations does, but at the same time adopting a meaning
for '@' that is closer to that of the second group, more like a
Javascript variable than a JSONPath expression. I expect more
clarification will make its way into the draft.

My only intent with these observations is to express scepticism about
whether it's even possible to have a JSONPath specification that
mirrors current practice. On many points, the answer to the question,
what do implementations do, is "It depends on what implementation you
look at." It looks to me that the WG is picking and choosing features
that they like from various implementations, and is moving towards an
end point that will be different in some way from all existing
implementations. If there was a strong vendor interest to have a
common understanding of JSONPath for future API's, that might work.
But I don't think there is. I don't think vendors would have any
interest in revisiting their legacy API's. And as for the present and
future, they appear to be more interested in W3C and Oasis efforts
around JsonIq.

>
> I see your post as a hint for us to perhaps concretise the 'nodelist' definition in the spec and check its use throughout the text.
> --
In my original remarks, I put the term "nodelist" in quotes, and
accepted its meaning as returning a sequence of something. I didn't
want to focus on that, my point was that for a significant part of the
JSONPath landscape, in expressions containing strings that start with
'@', there would be no sequence of anything, just one thing.

I concede that I have some difficulty with understanding the meaning
of "nodelist" as it's used in the draft :-) There are implementations,
e.g. https://www.npmjs.com/package/jsonpath, that support methods for
returning values, paths or nodes (path-value pairs) and I understand
what those mean. I don't understand what the draft  means by this
definition of Node List: "The output of applying a query to an
argument is manifested as a list of nodes. While this list can be
represented in JSON, e.g. as an array, the nodelist is an abstract
concept unrelated to JSON values." But that's another matter.

Daniel