Closed goessner closed 3 years ago
I have created new issues based on the agreed actions during the IETF 110 meeting - just to clarify those which are not already new issues:
This issue can be closed now, however please comment if there is any issue.
Hello List,
It has been important to go through this list threads carefully. In fact I should have done that at first. Now I can understand the current draft and appreciate the work already done much better.
I collected some citations (important from my point of view) with comments already in Markdown.
Title of the specification
There seems to be an agreement for "JSONPath: Query expressions for JSON". I like that also.
Terminology
I understand, that within RFC8259 we have JSON values of different types. They are structured somehow, which is not so much of interest here.
But while querying that structure with JSONPath it is vitally important to identify that hierarchical structure as a tree. So in fact we build up a higher-level construct here. We also need to call "the things" in the tree somehow. I was able to identify
but could not see an agreement here.
I agree to Glyn calling the term "union" poor (s. below).
Differentiation from JSON Pointer (JSONPath draft charter)
+1
References to XPath
It seemed to be important in 2007, while argumenting to have something like XPath for JSON. If nowadays the terminology used has changed significantly with XPath 2.0 and 3.0, we better leave that comparison table 2 out. I am quite passionless here.
Array Slice Operator
It's good having read this thread and thus understand the current draft much better. I like the decision to be consistent with Python and also getting an empty selection set with
step=0
.FYI: there is a recent proposal for adding slice notation syntax to JavaScript, currently at stage 1 of the TC39 process.
https://github.com/tc39/proposal-slice-notation
Interestingly it won't have a step argument ...
https://github.com/tc39/proposal-slice-notation#why-doesnt-this-include-a-step-argument-like-python-does
... because of syntax collision with the new
this-binding
syntax proposal::
https://github.com/tc39/proposal-bind-operator
However, we should not let us influence by this.
Unions
Introducing the union operator
[,]
simply was meant an analogon to XPath's operator'|'
. I cannot tell, if it was a simple combination of node sets in Xpath 1.0 or a true union without duplicates. I obviously was not aware of that subtle (essential ?) union characteristic.So I fully agree to Glyn Normington's '... the term “union” is poor' statement. Are there some better alternative terms, perhaps 'multi-index operator', 'index list', 'subscript list', etc.?
Duplicates and Ordering
I must confess to never having thought about duplicates, let alone wanting to eliminate them. So I do like Marko's comparison of 'selection-model' vs. 'collection-model' a lot. I would opt for the latter. In this sense the result of a 'JSONPath query expression' should be termed a 'collection'.
Regarding ordering I see something like a 'natural ordering', according to which
$..[0,1] ➔ [10, 20]
$..[1,0] ➔ [20, 10]
would result with the example above.
I do understand the use cases for reordering, duplicates removal, filtering, etc.. But this can always be seen as a postprocessing step on the resulting collection by handing it over to accompanying tools (think of pipe operator).
Of course this cannot work on the result collection of values alone (s. duplicate nodes vs. duplicate values above), it rather requires a collection of (normalized) pathes. In this sense, I like this view:
Filter Expressions
I tend to let implementations and their "normative force of the factual" decide here or in doubt agree to Glyn's restriction to arrays.
I am very unhappy with confusing
$..book[(@.length-1)]
, where'@'
addresses the array itself and implies that array has alength
property. In filter expression examples'@'
more consistently addresses the current array element.The invocation of 'the underlying scripting engine' wasn't meant a serious normative aspect, but rather a quick and dirty solution for JavaScript and PHP implementations at that time.
Corner Case
Hmm ... this seems to be a hint to better exclude
'-'
from dot-child-selector syntax. I think I have read more discussion about that, currently don't know where.Respect Implementations
+1 to all.
Error Handling
I like and totally agree with the forgiving mental model, so having only syntax errors, which do not dependent on data.
Thanks
-- sg