jiebi/CodeConvo huggingface dataset:
Code change:
Lots of niggly details re blank space. Style consistency, some missing places (assuming we stick with the liberal approach). Allowing "in" before or after a newline or tab. Adding some legend to the only remaining table with XPath content in the main document.
[ ] define a production , replacing [ ] go through ABNF and make sure blank space is allowed where it needs to be (Do not use the term "whitespace" any more.) Task "T1" in the document URL
and
From the document: (whitespace is now generally called blank space, but that doesn't change the work to be done.)
and
How much do we want to reference XPath within the spec? I understand that XPath is the inspiration (and in the tagline that NAME used in his blog post: "XPath for JSON"), but I wonder if much of this can be left out of the spec. The argument for this is that we're defining JSONPath. It shouldn't assume any understanding of XPath or any other technology. It's not the job of the specification to convince readers to use it. It's the job of the specification to define the technology. I'm perfectly happy moving this into an external "Understanding JSONPath" website at some point.
I seem to remember that last time we discussed this we agreed to move the introductory comparison with XPath to an appendix, with the possible exception of the overview table (but that could be duplicated).
The XPath inclusion was moved into an appendix.
Do we allow spaces (outside of string literals)? If so, where is whitespace allowed? I think whitespace in query expressions should be allowed. This would fall in to the context of the . Maybe inside the union/ selector: Are there any other places where whitespace could be considered useful?
It may be convenient to allow spaces between matchers - to allow well-readable multi-line queries for complex cases.
Looks like the allows whitespace internally, so that (with leading and trailing whitespace) is valid.
Closed in and
What was the resolution here? Where did we end up allowing whitespace?

Related discussion:
text: member name ""a"".  The result is again a list of one node: "[{"b":0},{"b":1},{"c":2}]". <del> Next, "[*]" selects from any input node -- either an array or an object -- all its elements or members.  The result is a list of three nodes: "{"b":0}", "{"b":1}", and "{"c":2}". </del> <ins> Next, "[*]" selects from an input node of type array all its elements (if the input note were of type object, it would select all its member values, but not the member names).  The result is a list of three nodes: "{"b":0}", "{"b":1}", and "{"c":2}". </ins> Finally, ".b" selects from any input node of type object with a member name "b" and selects the node of the member value of the input
Code change:
From the meeting at IETF 112 ([1]): Consensus: 'in' won't be used, but it will be easy to add later if there's real demand [1] URL
Good eyes. Thanks!
Yes, we agreed to remove the 'in' operator as some kind of syntactic sugar. thanks
Thanks! I pushed a small commit removing an "in" example.

Related discussion:
text: Regular expression tests can be applied to "string" values only. <del> The value of the first operand ("containable") of a "contain-expr" is compared to every single element of the RHS "container".  In case of a match a selection occurs.  Containment tests -- like comparisons -- are restricted to primitive values.  So even if a structured "containable" value is equal to a certain structured value in "container", no selection is done. The value of the second operand ("container") of a "contain-expr" needs to be resolved to an array.  Otherwise nothing is selected. </del> The following table lists filter expression operators in order of precedence from highest (binds most tightly) to lowest (binds least tightly).
Code change:
NAME It would be good to address NAME comments in this PR. I have made some suggestions, but feel free to pick them apart if you are keen to retain "truthiness" and "falsiness". BTW perhjaps I struggle with the latter term because of the existence of some .
Indeed. It is not that easy to say here what needs to be said, so I'm still in thinking mode. Thanks for the pointer to English slang; of course I was completely unaware. We don't want to use the fooiness terms. Interestingly, the remaining grammar does not seem to have a place where JSON values are implicitly converted to Boolean; this is now all explicit unless I'm missing something. So maybe we don't need this table (and its legend) at all?
You're right! The two occurrences of are as follows. which simply tests for non-existence of a value(s) selected by a path and does not depend on the actual values themselves. which negates a boolean expression. Looking at the details of , there's no way it can result in a value which might need to be converted to boolean. So please can we scrap the table and kiss "fooiness" goodbye once and for all?
I think we should first merge it and then delete it, in case we need to resurrect it later.
what's about ... which can surely be converted to a negated form. But sometimes someone doesn't want to do that ... like in any programming language. Nevertheless I second to kick fooiness out. As a minimalist I am always a friend of kicking unneeded things out.
Comparisons already yield Boolean values, as does /.
Well, then in fact I misunderstood Glyn's comment above ... I agree to remove the conversion table as superfluous.

Related discussion:
text: to the member name from any JSON object in its input nodelist.  It selects no nodes from any other JSON value. <del> Note that the "dot-selector" follows the philosophy of JSON strings and is allowed to contain bit sequences that cannot encode Unicode characters (a single unpaired UTF-16 surrogate, for example).  The behaviour of an implementation is undefined for member names which do not encode Unicode characters. </del> 3.5.3. 3.5.3.1.
Code change:
NAME It would be good to address NAME comments in this PR. I have made some suggestions, but feel free to pick them apart if you are keen to retain "truthiness" and "falsiness". BTW perhjaps I struggle with the latter term because of the existence of some .
Indeed. It is not that easy to say here what needs to be said, so I'm still in thinking mode. Thanks for the pointer to English slang; of course I was completely unaware. We don't want to use the fooiness terms. Interestingly, the remaining grammar does not seem to have a place where JSON values are implicitly converted to Boolean; this is now all explicit unless I'm missing something. So maybe we don't need this table (and its legend) at all?
You're right! The two occurrences of are as follows. which simply tests for non-existence of a value(s) selected by a path and does not depend on the actual values themselves. which negates a boolean expression. Looking at the details of , there's no way it can result in a value which might need to be converted to boolean. So please can we scrap the table and kiss "fooiness" goodbye once and for all?
I think we should first merge it and then delete it, in case we need to resurrect it later.
what's about ... which can surely be converted to a negated form. But sometimes someone doesn't want to do that ... like in any programming language. Nevertheless I second to kick fooiness out. As a minimalist I am always a friend of kicking unneeded things out.
Comparisons already yield Boolean values, as does /.
Well, then in fact I misunderstood Glyn's comment above ... I agree to remove the conversion table as superfluous.

Related discussion:
text: of their element or member values then.  Applied to other value types, it will select nothing. <del> : The zero number/empty string exceptions are no longer true. Booleans work the same everywhere. Negation operator "neg-op" allows to test of values. Applying negation operator twice "!!" gives us </del> <ins> DELETE-ME: (( We currently don't need this.  But we commit a version in case we do need it later.  The negation operator "neg-op" can be applied to any JSON value and returns "true" only when applied to "false" or "null": </ins> <del> of values. </del> <ins> Consequently, applying the negation operator twice "!!" returns "true" for all values except "false" or "null".  )) </ins> Some examples:
Code change:
Also add some general advice from URL See also . Ref: URL
Recursion is not really the problem, stack depth is (or any other uncontrolled resource usage triggered by queries into deeply nested structures). Grüße, Carsten
NAME Are you comfortable with this now, or would you perhaps like to suggest some other way to address the concerns of URL
Thank you.Looks good and informative to me.

Related discussion:
text: D.draft-bormann-jsonpath-iregexp for performance issues in regular expression implementations.)  Implementers need to be aware that good average performance is not sufficient as long as an attacker can <del> choose to submit specially crafted JSONPath queries that trigger surprisingly high, possibly exponential, CPU usage. </del> <ins> choose to submit specially crafted JSONPath queries or arguments that trigger surprisingly high, possibly exponential, CPU usage or, for example via a naive recursive implementation of the descendant selector, stack overflow.  Implementations need to have appropriate resource management to mitigate these attacks. </ins> 5.2.
Code change:
This is probably a bit too wordy, but is a starting point for a sharper definition of the nodelist orders which can be produced by the descendant selector. Ref: URL
I'm not sure of the context. Please could you point out particular lines. (The usual way to do this is to enter your review by clicking a "+" which appears when you hover the mouse pointer just to the left of a line in the "Files changed" tab of the PR. You can comment on a block of lines by clicking on the line number of the first line of the block and then shift-clicking on the line number of the last line of the block.) Meta comment: thanks for your review. I'm afraid it's non-binding. See on the mailing list.
I created local comments as requested per NAME Well, let us keep that discussion in that list maybe? Actually, Stefan Hagen's kind approvals are not binding, so I will await your approval, Carsten, or someone else's with the appropriate privileges. (I could give Stefan those privileges, but that seems wrong!) In fact, I'm puzzled over who can approve PRs (in a binding way). The repository settings list four people with direct access to the repo (see the attached screenshot), but then there are cabo, timbray, and probably some other users with binding PR approval privileges. I'm not sure how we arrived at this set of people. Maybe someone will remember... On Tue, 12 Jul 2022 at 20:16, Glyn Normington wrote:

Related discussion:
text: "index-wild-selector", "filter-selector", or "list-selector" acting on objects or arrays, or a "slice-selector" acting on arrays. <del> Note that there is no "bald" descendant selector "..". </del> <ins> Note that there is no "bald" descendant selector (".." on its own). </ins> 3.5.7.2. <del> The "descendant-selector" selects certain descendants of a node: </del> <ins> A "descendant-selector" selects certain descendants of a node: </ins> the "..<name>" form (and the "..[<index>]" form where "<index>" is a "quoted-member-name") selects those descendants that are member
Code change:
This is probably a bit too wordy, but is a starting point for a sharper definition of the nodelist orders which can be produced by the descendant selector. Ref: URL
I'm not sure of the context. Please could you point out particular lines. (The usual way to do this is to enter your review by clicking a "+" which appears when you hover the mouse pointer just to the left of a line in the "Files changed" tab of the PR. You can comment on a block of lines by clicking on the line number of the first line of the block and then shift-clicking on the line number of the last line of the block.) Meta comment: thanks for your review. I'm afraid it's non-binding. See on the mailing list.
I created local comments as requested per NAME Well, let us keep that discussion in that list maybe? Actually, Stefan Hagen's kind approvals are not binding, so I will await your approval, Carsten, or someone else's with the appropriate privileges. (I could give Stefan those privileges, but that seems wrong!) In fact, I'm puzzled over who can approve PRs (in a binding way). The repository settings list four people with direct access to the repo (see the attached screenshot), but then there are cabo, timbray, and probably some other users with binding PR approval privileges. I'm not sure how we arrived at this set of people. Maybe someone will remember... On Tue, 12 Jul 2022 at 20:16, Glyn Normington wrote:

Related discussion:
text: the "..[*]" and "..*" forms select all the descendants. <del> The resultant nodelist is ordered as if: </del> <ins> An </ins> <del> nodes are visited before their children, and </del> <ins> of the descendants of a node is a sequence of all the descendants in which: </ins> <del> nodes of an array are visited in array order. </del> <ins> nodes of any array appear in array order, </ins> <del> Children of an object may be visited in any order, since JSON objects are unordered. </del> <ins> nodes appear immediately before all their descendants. </ins> <del> Implementations may visit descendants in any way providing the resultant nodelist could have been produced by visiting descendants as above. </del> <ins> This definition does not stipulate the order in which the children of an object appear, since JSON objects are unordered. The resultant nodelist of a "descendant-selector" applied to a node must be a sub-sequence of an array-sequenced preorder of the descendants of the node. </ins> 3.5.7.3.
Code change:
Fixes URL
Thanks for your comments NAME and NAME I feel I should explain. The current draft defines the orderings and using the same text. For strings, the text talks about "less than" but not "greater than". So the current text implicitly assumes that for strings and , if and only if . Non-mathematicians would tend to say this is patently obvious. But this PR avoids that assumption by only defining using the same text and then defining in terms of . However, I take the point about the standalone definitions and the arbitrariness of defining one in terms of the other. So my question is: is the current draft text sufficiently precise? If not, I'll rework this PR to make it more precise. (When I started out doing that, it began to get quite wordy, so I changed tack.)
Despite the fact, that Glyn's approach is mathematically clean, I would favour the symmetric approach by defining , ,. I am quite sure, that nobody will cry "redundancy" then.
Yes. Is that a problem? comes before ...
Actually, on the symmetry point, we were comfortable defining in terms of and that was asymmetric.
In what system of mathematics are operations ordered? This is completely arbitrary. I'm not convinced this needs to change. I prefer defining both and . And for symmetry, I'd change strings to match.
Applying editorial discretion here. Merging.
The current spec defines string comparison using one of the operators , , , or in terms of when one string is less than another. That's fine for , but: for it effectively assumes is fixed (i.e. that for strings and if or ) for and it leaves quite a lot to the reader's imagination. Once we've settled on , the above should be addressed. ~We should also adopt a similar approach for ordered comparisons () of arrays if is adopted.~ (It wasn't.) (I labelled this issue as because I don't believe it will change the intended semantics in either case.)
I propose to let URL land before addressing this issue.
I personally prefer the previous version, with standalone definitions, but think this is a matter of editorial discretion.I agree with Tim. It's fine and correct to define in terms of other operators, but I feel and should both be equally defined. Defining one in terms of the other means you have to make an arbitrary choice of which is directly defined and which is indirectly defined.This PR is exactly the right way to do this.

Related discussion:
text: 3.5.5.2.2. <del> The comparison operators "==", "<", and ">" are defined first and then these are used to define "!=", "<=", and ">=". </del> <ins> The comparison operators "==" and "<" are defined first and then these are used to define "!=", "<=", ">", and ">=". </ins> When a path resulting in an empty nodelist appears on either side of a comparison:
Code change:
Fixes URL
Thanks for your comments NAME and NAME I feel I should explain. The current draft defines the orderings and using the same text. For strings, the text talks about "less than" but not "greater than". So the current text implicitly assumes that for strings and , if and only if . Non-mathematicians would tend to say this is patently obvious. But this PR avoids that assumption by only defining using the same text and then defining in terms of . However, I take the point about the standalone definitions and the arbitrariness of defining one in terms of the other. So my question is: is the current draft text sufficiently precise? If not, I'll rework this PR to make it more precise. (When I started out doing that, it began to get quite wordy, so I changed tack.)
Despite the fact, that Glyn's approach is mathematically clean, I would favour the symmetric approach by defining , ,. I am quite sure, that nobody will cry "redundancy" then.
Yes. Is that a problem? comes before ...
Actually, on the symmetry point, we were comfortable defining in terms of and that was asymmetric.
In what system of mathematics are operations ordered? This is completely arbitrary. I'm not convinced this needs to change. I prefer defining both and . And for symmetry, I'd change strings to match.
Applying editorial discretion here. Merging.
The current spec defines string comparison using one of the operators , , , or in terms of when one string is less than another. That's fine for , but: for it effectively assumes is fixed (i.e. that for strings and if or ) for and it leaves quite a lot to the reader's imagination. Once we've settled on , the above should be addressed. ~We should also adopt a similar approach for ordered comparisons () of arrays if is adopted.~ (It wasn't.) (I labelled this issue as because I don't believe it will change the intended semantics in either case.)
I propose to let URL land before addressing this issue.
I personally prefer the previous version, with standalone definitions, but think this is a matter of editorial discretion.I agree with Tim. It's fine and correct to define in terms of other operators, but I feel and should both be equally defined. Defining one in terms of the other means you have to make an arbitrary choice of which is directly defined and which is indirectly defined.This PR is exactly the right way to do this.

Related discussion:
text: the comparison is between two paths each of which result in an empty nodelist. <del> a comparison using either of the operators "<" or ">" yields false. </del> <ins> a comparison using the operator "<" yields false. </ins> When any path on either side of a comparison results in a nodelist consisting of a single node, each such path is replaced by the value
Code change:
Fixes URL
Thanks for your comments NAME and NAME I feel I should explain. The current draft defines the orderings and using the same text. For strings, the text talks about "less than" but not "greater than". So the current text implicitly assumes that for strings and , if and only if . Non-mathematicians would tend to say this is patently obvious. But this PR avoids that assumption by only defining using the same text and then defining in terms of . However, I take the point about the standalone definitions and the arbitrariness of defining one in terms of the other. So my question is: is the current draft text sufficiently precise? If not, I'll rework this PR to make it more precise. (When I started out doing that, it began to get quite wordy, so I changed tack.)
Despite the fact, that Glyn's approach is mathematically clean, I would favour the symmetric approach by defining , ,. I am quite sure, that nobody will cry "redundancy" then.
Yes. Is that a problem? comes before ...
Actually, on the symmetry point, we were comfortable defining in terms of and that was asymmetric.
In what system of mathematics are operations ordered? This is completely arbitrary. I'm not convinced this needs to change. I prefer defining both and . And for symmetry, I'd change strings to match.
Applying editorial discretion here. Merging.
The current spec defines string comparison using one of the operators , , , or in terms of when one string is less than another. That's fine for , but: for it effectively assumes is fixed (i.e. that for strings and if or ) for and it leaves quite a lot to the reader's imagination. Once we've settled on , the above should be addressed. ~We should also adopt a similar approach for ordered comparisons () of arrays if is adopted.~ (It wasn't.) (I labelled this issue as because I don't believe it will change the intended semantics in either case.)
I propose to let URL land before addressing this issue.
I personally prefer the previous version, with standalone definitions, but think this is a matter of editorial discretion.I agree with Tim. It's fine and correct to define in terms of other operators, but I feel and should both be equally defined. Defining one in terms of the other means you have to make an arbitrary choice of which is directly defined and which is indirectly defined.This PR is exactly the right way to do this.

Related discussion:
text: for each of those names, the values associated with the name by the objects are equal. <del> a comparison using either of the operators "<" or ">" yields true if and only if the comparison is between values of the same type which are both numbers or both strings and which satisfy the comparison: </del> <ins> a comparison using the operator "<" yields true if and only if the comparison is between values of the same type which are both numbers or both strings and which satisfy the comparison: </ins> numbers expected to interoperate as per RFC7493 MUST compare using the normal mathematical ordering; numbers not expected to