jiebi/TextFlow huggingface dataset:
Original 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).

Reviewer comments:
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.

Revised text:
Regular expression tests can be applied to "string" values only.  The following table lists filter expression operators in order of precedence from highest (binds most tightly) to lowest (binds least tightly).
Original 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.

Reviewer comments:
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.

Revised text:
to the member name from any JSON object in its input nodelist.  It selects no nodes from any other JSON value.  3.5.3. 3.5.3.1.
Original 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>  <del> of values. </del>  Some examples:

Reviewer comments:
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.

Revised text:
of their element or member values then.  Applied to other value types, it will select nothing.  <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>  <ins> Consequently, applying the negation operator twice "!!" returns "true" for all values except "false" or "null".  )) </ins> Some examples:
Original 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>  5.2.

Reviewer comments:
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.

Revised 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  <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.
Original 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>  3.5.7.2. <del> The "descendant-selector" selects certain descendants of a node: </del>  the "..<name>" form (and the "..[<index>]" form where "<index>" is a "quoted-member-name") selects those descendants that are member

Reviewer comments:
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:

Revised text:
"index-wild-selector", "filter-selector", or "list-selector" acting on objects or arrays, or a "slice-selector" acting on arrays.  <ins> Note that there is no "bald" descendant selector (".." on its own). </ins> 3.5.7.2.  <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
Original text:
the "..[*]" and "..*" forms select all the descendants. <del> The resultant nodelist is ordered as if: </del>  <del> nodes are visited before their children, and </del>  <del> nodes of an array are visited in array order. </del>  <del> Children of an object may be visited in any order, since JSON objects are unordered. </del>  <del> Implementations may visit descendants in any way providing the resultant nodelist could have been produced by visiting descendants as above. </del>  3.5.7.3.

Reviewer comments:
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:

Revised text:
the "..[*]" and "..*" forms select all the descendants.  <ins> An </ins>  <ins> of the descendants of a node is a sequence of all the descendants in which: </ins>  <ins> nodes of any array appear in array order, </ins>  <ins> nodes appear immediately before all their descendants. </ins>  <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.
Original text:
3.5.5.2.2. <del> The comparison operators "==", "<", and ">" are defined first and then these are used to define "!=", "<=", and ">=". </del>  When a path resulting in an empty nodelist appears on either side of a comparison:

Reviewer comments:
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.

Revised text:
3.5.5.2.2.  <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:
Original 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>  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

Reviewer comments:
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.

Revised text:
the comparison is between two paths each of which result in an empty nodelist.  <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
Original text:
The comparison "a <= b" yields true if and only if "a < b" yields true or "a == b" yields true. <del> The comparison "a >= b" yields true if and only if "a > b" yields </del>  true or "a == b" yields true. 3.5.5.2.3.

Reviewer comments:
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.

Revised text:
The comparison "a <= b" yields true if and only if "a < b" yields true or "a == b" yields true.  <ins> The comparison "a > b" yields true if and only if "b < a" yields true. The comparison "a >= b" yields true if and only if "b < a" yields </ins> true or "a == b" yields true. 3.5.5.2.3.
Original text:
Security considerations for JSONPath can stem from <del> attack vectors on JSONPath implementations, and </del>  the way JSONPath is used in security-relevant mechanisms.

Reviewer comments:
We wanted to add examples, but maybe we can merge this as is. Marking as ready for review.
Let's get this in and polish it later.

Revised text:
Security considerations for JSONPath can stem from  <ins> attack vectors on JSONPath implementations, attack vectors on how JSONPath queries are formed, and </ins> the way JSONPath is used in security-relevant mechanisms.
Original text:
4.2.  Where JSONPath is used as a part of a security mechanism, attackers can attempt to provoke unexpected or unpredictable behavior, or take advantage of differences in behavior between JSONPath

Reviewer comments:
We wanted to add examples, but maybe we can merge this as is. Marking as ready for review.
Let's get this in and polish it later.

Revised text:
4.2. <ins> JSONPath queries are often not static, but formed from variables that provide index values, member names, or values to compare with in a filter expression.  These variables need to be translated into the form they take in a JSONPath query, e.g., by escaping string delimiters, or by only allowing specific constructs such as ".name" to be formed when the given values allow that.  Failure to perform these translations correctly can lead to unexpected failures, which can lead to Availability, Confidentiality, and Integrity breaches, in particular if an adversary has control over the values (e.g., by entering them into a Web form).  The resulting class of attacks, (e.g., SQL injections), is consistently found among the top causes of application security vulnerabilities and requires particular attention. 4.3. </ins> Where JSONPath is used as a part of a security mechanism, attackers can attempt to provoke unexpected or unpredictable behavior, or take advantage of differences in behavior between JSONPath
Original text:
Comparison expressions are available for comparisons between primitive values (that is, numbers, strings, "true", "false", and <del> "null").  These can be obtained via literal values; Singular Paths, </del>  each of which selects at most one node the value of which is then used; and function expressions (see fnex) of type "ValueType" or "NodesType" (see type-conv).

Reviewer comments:
XPath terminology is a bit weird, because XPath has a somewhat competing standard XQuery... XPath is based on DSSSL, which had a complex expression language for building paths in the XML trees that was based on the Scheme language. (Which is the experience that makes me hesitant just jumping headlong into another expression language...)
LGTM with that change. Thanks!

Revised text:
Comparison expressions are available for comparisons between primitive values (that is, numbers, strings, "true", "false", and  <ins> "null").  These can be obtained via literal values; Singular Queries, </ins> each of which selects at most one node the value of which is then used; and function expressions (see fnex) of type "ValueType" or "NodesType" (see type-conv).