jiebi/TextFlow huggingface dataset:
Original text:
2.5.5.2.1. <del> A path by itself in a Logical context is an existence test which yields true if the path selects at least one node and yields false if the path does not select any nodes. </del>  Existence tests differ from comparisons in that: <del> they work with arbitrary relative or absolute paths (not just Singular Paths). </del>  <del> they work with paths that select structured values. </del>  <del> To examine the value of a node selected by a path, an explicit </del>  comparison is necessary.  For example, to test whether the node <del> selected by the path "@.foo" has the value "null", use "@.foo == </del>  null" (see null-semantics) rather than the negated existence test "!@.foo" (which yields false if "@.foo" selects a node, regardless of the node's value).

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:
2.5.5.2.1.  <ins> A query by itself in a Logical context is an existence test which yields true if the query selects at least one node and yields false if the query does not select any nodes. </ins> Existence tests differ from comparisons in that:  <ins> they work with arbitrary relative or absolute queries (not just Singular Queries). </ins>  <ins> they work with queries that select structured values. </ins>  <ins> To examine the value of a node selected by a query, an explicit </ins> comparison is necessary.  For example, to test whether the node  <ins> selected by the query "@.foo" has the value "null", use "@.foo == </ins> null" (see null-semantics) rather than the negated existence test "!@.foo" (which yields false if "@.foo" selects a node, regardless of the node's value).
Original text:
a comparison using the operator "<" yields false. <del> When any path or function expression on either side of a comparison </del>  results in a nodelist consisting of a single node, that side is replaced by the value of its node and then:

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:
a comparison using the operator "<" yields false.  <ins> When any query or function expression on either side of a comparison </ins> results in a nodelist consisting of a single node, that side is replaced by the value of its node and then:
Original text:
implementation level only -- they do not influence the result of the evaluation.) <del> A function argument is a "filter-path" or a "comparable". </del>  According to filter-selector, a "function-expr" is valid as a <del> "filter-path" or a "comparable". </del>  Any function expressions in a query must be well-formed (by conforming to the above ABNF) and well-typed, otherwise the JSONPath

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:
implementation level only -- they do not influence the result of the evaluation.)  <ins> A function argument is a "filter-query" or a "comparable". </ins> According to filter-selector, a "function-expr" is valid as a  <ins> "filter-query" or a "comparable". </ins> Any function expressions in a query must be well-formed (by conforming to the above ABNF) and well-typed, otherwise the JSONPath
Original text:
related to the JSON literals "true" and "false" and have no direct syntactical representation in JSONPath. <del> "NodesType" is an abstraction of a "filter-path" (which appears in a test expression or as a function argument).  Members of </del>  "NodesType" have no direct syntactical representation in JSONPath. The abstract instances above can be obtained from the concrete

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:
related to the JSON literals "true" and "false" and have no direct syntactical representation in JSONPath.  <ins> "NodesType" is an abstraction of a "filter-query" (which appears in a test expression or as a function argument).  Members of </ins> "NodesType" have no direct syntactical representation in JSONPath. The abstract instances above can be obtained from the concrete
Original text:
The argument is a literal primitive value and the defined type of the parameter is "ValueType". <del> The argument is a Singular Path or "filter-path" (which includes Singular Paths), or a function expression with </del>  declared result type "NodesType" and the defined type of the parameter is "NodesType".  Where the declared type of the parameter is not "NodesType", a conversion applies.

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:
The argument is a literal primitive value and the defined type of the parameter is "ValueType".  <ins> The argument is a Singular Query or "filter-query" (which includes Singular Queries), or a function expression with </ins> declared result type "NodesType" and the defined type of the parameter is "NodesType".  Where the declared type of the parameter is not "NodesType", a conversion applies.
Original text:
filter expression: Its only argument is an instance of "ValueType" (possibly taken from <del> a singular path as in the example above).  The result also is an </del>  instance of "ValueType": an unsigned integer or "Nothing". If the argument value is a string, the result is the number of

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:
filter expression: Its only argument is an instance of "ValueType" (possibly taken from  <ins> a singular query as in the example above).  The result also is an </ins> instance of "ValueType": an unsigned integer or "Nothing". If the argument value is a string, the result is the number of
Original text:
processing in the filter expression: Its only argument is an instance of "NodesType" (possibly taken from <del> a "filter-path" as in the example above).  The result is an instance </del>  of "ValueType". If the argument contains a single node, the result is the value of

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:
processing in the filter expression: Its only argument is an instance of "NodesType" (possibly taken from  <ins> a "filter-query" as in the example above).  The result is an instance </ins> of "ValueType". If the argument contains a single node, the result is the value of
Original text:
Certain characters are escaped, in one and only one way; all other characters are unescaped. <del> Note: Normalized Paths are Singular Paths, but not all Singular Paths are Normalized Paths.  For example, "$[-3]" is a Singular Path, but is not a Normalized Path.  The Normalized Path equivalent to "$[-3]" would have an index equal to the array length minus "3".  (The array length must be at least "3" if "$[-3]" is to identify a node.) </del>  Since there can only be one Normalized Path identifying a given node, the syntax stipulates which characters are escaped and which are not.

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:
Certain characters are escaped, in one and only one way; all other characters are unescaped.  <ins> Note: Normalized Paths are Singular Queries, but not all Singular Queries are Normalized Paths.  For example, "$[-3]" is a Singular Query, but is not a Normalized Path.  The Normalized Path equivalent to "$[-3]" would have an index equal to the array length minus "3". (The array length must be at least "3" if "$[-3]" is to identify a node.) </ins> Since there can only be one Normalized Path identifying a given node, the syntax stipulates which characters are escaped and which are not.
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 Queries, </del>  each of which selects at most one node the value of which is then used; or function expressions (see fnex) of type "ValueType".

Reviewer comments:
Sometimes the spec uses "Singular Query" and sometimes "singular query". We should be consistent. (If we decide to use lower case, it's probably best to address this issue after PR has been merged, since that PR adds some usages of "Singular Query".) Also, there is one instance of "Logical context", which I think would be better uncapitalised ("logical context").
After merging in my changes from main, it appears some Singular Queries still need fixing.

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; or function expressions (see fnex) of type "ValueType".
Original text:
Existence tests differ from comparisons in that: they work with arbitrary relative or absolute queries (not just <del> Singular Queries). </del>  they work with queries that select structured values.

Reviewer comments:
Sometimes the spec uses "Singular Query" and sometimes "singular query". We should be consistent. (If we decide to use lower case, it's probably best to address this issue after PR has been merged, since that PR adds some usages of "Singular Query".) Also, there is one instance of "Logical context", which I think would be better uncapitalised ("logical context").
After merging in my changes from main, it appears some Singular Queries still need fixing.

Revised text:
Existence tests differ from comparisons in that: they work with arbitrary relative or absolute queries (not just  <ins> singular queries). </ins> they work with queries that select structured values.
Original text:
Certain characters are escaped in Normalized Paths, in one and only one way; all other characters are unescaped. <del> Note: Normalized Paths are Singular Queries, but not all Singular Queries are Normalized Paths.  For example, "$[-3]" is a singular </del>  query, but is not a Normalized Path.  The Normalized Path equivalent to "$[-3]" would have an index equal to the array length minus "3". (The array length must be at least "3" if "$[-3]" is to identify a

Reviewer comments:
Sometimes the spec uses "Singular Query" and sometimes "singular query". We should be consistent. (If we decide to use lower case, it's probably best to address this issue after PR has been merged, since that PR adds some usages of "Singular Query".) Also, there is one instance of "Logical context", which I think would be better uncapitalised ("logical context").
After merging in my changes from main, it appears some Singular Queries still need fixing.

Revised text:
Certain characters are escaped in Normalized Paths, in one and only one way; all other characters are unescaped.  <ins> Note: Normalized Paths are singular queries, but not all singular queries are Normalized Paths.  For example, "$[-3]" is a singular </ins> query, but is not a Normalized Path.  The Normalized Path equivalent to "$[-3]" would have an index equal to the array length minus "3". (The array length must be at least "3" if "$[-3]" is to identify a
Original text:
, as described in fnex. A JSONPath implementation MUST raise an error for any query which is <del> not well-formed and valid.  The well-formedness and the validity of </del>  JSONPath queries are independent of the JSON value the query is applied to.  No further errors relating to the well-formedness and the validity of a JSONPath query can be raised during application of

Reviewer comments:
Also, delete a term which is used only in the definition of the next term. Fixes URL
I only found the two occurrences you suggested changing. If there are others, please let me know!
Sometimes the spec uses "Singular Query" and sometimes "singular query". We should be consistent. (If we decide to use lower case, it's probably best to address this issue after PR has been merged, since that PR adds some usages of "Singular Query".) Also, there is one instance of "Logical context", which I think would be better uncapitalised ("logical context").
Thanks.

Revised text:
, as described in fnex. A JSONPath implementation MUST raise an error for any query which is  <ins> not well formed and valid.  The well-formedness and the validity of </ins> JSONPath queries are independent of the JSON value the query is applied to.  No further errors relating to the well-formedness and the validity of a JSONPath query can be raised during application of
Original text:
the result is "LogicalTrue"; if the function's declared result type is "NodesType", it tests whether the result is non-empty.  If the function's declared result type is "ValueType", its use in a test <del> expression is not well-typed. </del>  Comparison expressions are available for comparisons between primitive values (that is, numbers, strings, "true", "false", and

Reviewer comments:
Also, delete a term which is used only in the definition of the next term. Fixes URL
I only found the two occurrences you suggested changing. If there are others, please let me know!
Sometimes the spec uses "Singular Query" and sometimes "singular query". We should be consistent. (If we decide to use lower case, it's probably best to address this issue after PR has been merged, since that PR adds some usages of "Singular Query".) Also, there is one instance of "Logical context", which I think would be better uncapitalised ("logical context").
Thanks.

Revised text:
the result is "LogicalTrue"; if the function's declared result type is "NodesType", it tests whether the result is non-empty.  If the function's declared result type is "ValueType", its use in a test  <ins> expression is not well typed. </ins> Comparison expressions are available for comparisons between primitive values (that is, numbers, strings, "true", "false", and
Original text:
2.5.5.2.1. <del> A query by itself in a Logical context is an existence test which </del>  yields true if the query selects at least one node and yields false if the query does not select any nodes.

Reviewer comments:
Also, delete a term which is used only in the definition of the next term. Fixes URL
I only found the two occurrences you suggested changing. If there are others, please let me know!
Sometimes the spec uses "Singular Query" and sometimes "singular query". We should be consistent. (If we decide to use lower case, it's probably best to address this issue after PR has been merged, since that PR adds some usages of "Singular Query".) Also, there is one instance of "Logical context", which I think would be better uncapitalised ("logical context").
Thanks.

Revised text:
2.5.5.2.1.  <ins> A query by itself in a logical context is an existence test which </ins> yields true if the query selects at least one node and yields false if the query does not select any nodes.
Original text:
implementation level only -- they do not influence the result of the evaluation.) <del> Any function expressions in a query must be well-formed (by conforming to the above ABNF) and well-typed, otherwise the JSONPath </del>  implementation MUST raise an error (see synsem-overview).  To define <del> which function expressions are well-typed, a type system is first </del>  introduced. 2.6.1.

Reviewer comments:
Also, delete a term which is used only in the definition of the next term. Fixes URL
I only found the two occurrences you suggested changing. If there are others, please let me know!
Sometimes the spec uses "Singular Query" and sometimes "singular query". We should be consistent. (If we decide to use lower case, it's probably best to address this issue after PR has been merged, since that PR adds some usages of "Singular Query".) Also, there is one instance of "Logical context", which I think would be better uncapitalised ("logical context").
Thanks.

Revised text:
implementation level only -- they do not influence the result of the evaluation.)  <ins> Any function expressions in a query must be well formed (by conforming to the above ABNF) and well typed, otherwise the JSONPath </ins> implementation MUST raise an error (see synsem-overview).  To define  <ins> which function expressions are well typed, a type system is first </ins> introduced. 2.6.1.
Original text:
If the argument is "Nothing" or contains multiple nodes, the result is "Nothing". <del> Note: a Singular Query may be used anywhere where a ValueType is </del>  expected, so there is no need to use the "value" function extension <del> with a Singular Query. </del>  2.6.9.

Reviewer comments:
Also, delete a term which is used only in the definition of the next term. Fixes URL
I only found the two occurrences you suggested changing. If there are others, please let me know!
Sometimes the spec uses "Singular Query" and sometimes "singular query". We should be consistent. (If we decide to use lower case, it's probably best to address this issue after PR has been merged, since that PR adds some usages of "Singular Query".) Also, there is one instance of "Logical context", which I think would be better uncapitalised ("logical context").
Thanks.

Revised text:
If the argument is "Nothing" or contains multiple nodes, the result is "Nothing".  <ins> Note: a singular query may be used anywhere where a ValueType is </ins> expected, so there is no need to use the "value" function extension  <ins> with a singular query. </ins> 2.6.9.
Original text:
one way; all other characters are unescaped. Note: Normalized Paths are Singular Queries, but not all Singular <del> Queries are Normalized Paths.  For example, "$[-3]" is a Singular Query, but is not a Normalized Path.  The Normalized Path equivalent </del>  to "$[-3]" would have an index equal to the array length minus "3". (The array length must be at least "3" if "$[-3]" is to identify a node.)

Reviewer comments:
Also, delete a term which is used only in the definition of the next term. Fixes URL
I only found the two occurrences you suggested changing. If there are others, please let me know!
Sometimes the spec uses "Singular Query" and sometimes "singular query". We should be consistent. (If we decide to use lower case, it's probably best to address this issue after PR has been merged, since that PR adds some usages of "Singular Query".) Also, there is one instance of "Logical context", which I think would be better uncapitalised ("logical context").
Thanks.

Revised text:
one way; all other characters are unescaped. Note: Normalized Paths are Singular Queries, but not all Singular  <ins> Queries are Normalized Paths.  For example, "$[-3]" is a singular query, but is not a Normalized Path.  The Normalized Path equivalent </ins> to "$[-3]" would have an index equal to the array length minus "3". (The array length must be at least "3" if "$[-3]" is to identify a node.)
Original text:
example, the Unicode PLACE OF INTEREST SIGN (U+2318) would be defined in ABNF as "%x2318".  The terminology of RFC8259 applies except where clarified below.  The terms "Primitive" and "Structured" are used to group different kinds of values as in RFC8259; JSON Objects and Arrays are structured, all

Reviewer comments:
Use parentheses as an indication that something is a function. Also, don't confuse the reader by alluding to potential future alternatives to value(). Reviewers: is this an improvement? It's a draft PR for now until we decide the change is worthwhile.
I think we'll need to explain the () notation, which should be familiar to C programmers but not necessarily to people who grew up on other languages. I also think we have a few more examples that point to hypothetical functions, such as , , .
I don't think there's a great point at which to explain that notation and, based on your observation, I'm going off the idea.
NAME Let's see how pans out before taking the current PR any further. Once I remove the function parentheses, the two PRs are changing the same text.
would be the place.
NAME As you suggested, I introduced this in 1.1, but near the start since it's notation rather than terminology. I did a regexp search to find and fix the remaining examples (your list was complete). In doing so, I found the strange markup and removed the backticks since there was no good reason for them.
We could do the fun() explanation and completeness search in a separate PR.

Revised text:
example, the Unicode PLACE OF INTEREST SIGN (U+2318) would be defined in ABNF as "%x2318". <ins> Functions are referred to using the function name followed by a pair of parentheses, as in "fname()". </ins> The terminology of RFC8259 applies except where clarified below.  The terms "Primitive" and "Structured" are used to group different kinds of values as in RFC8259; JSON Objects and Arrays are structured, all