jiebi/TextFlow huggingface dataset:
Original text:
indexing beyond the end of an array, simply result in fewer nodes being selected. <del> Let's walk through an example in detail.  With the argument </del>  "{"a":[{"b":0},{"b":1},{"c":2}]}", the query "$.a[*].b" selects the following list of nodes: "0", "1" (denoted here by their value).

Reviewer comments:
Fixes URL
In a previous issue, I suggested the idea of adding a processing model description to the specification. So was added. However, in re-reading the current document, I found that the process is repeated (albeit with less detail) in . I think that the language in 3.4 may be sufficient to explain how the path is expected to operate, making the processing model (or at least one of them) somewhat redundant. Can we combine these sections in some way instead of repeating ourselves?
I agree that we could combine these sections and avoid some repetition. I'm inclined to keep the Semantics section and do away with the Processing Model section since I think the term "Processing Model" is a little obscure compared to "Semantics".
Regardless of my question I like the change.

Revised text:
indexing beyond the end of an array, simply result in fewer nodes being selected.  <ins> Consider this example.  With the argument </ins> "{"a":[{"b":0},{"b":1},{"c":2}]}", the query "$.a[*].b" selects the following list of nodes: "0", "1" (denoted here by their value).
Original text:
Abstract JSONPath defines a string syntax for selecting and extracting values <del> within a JavaScript Object Notation (JSON, RFC 8259) value. </del>  1. <del> JavaScript Object Notation (JSON, RFC8259) is a popular representation format for structured data values.  JSONPath defines a string syntax for identifying values within a JSON value. </del>  JSONPath is not intended as a replacement for, but as a more powerful companion to, JSON Pointer RFC6901.  See json-pointer.

Reviewer comments:
because it is no longer needed because the expansion is misleading
Why is the expansion misleading?
I would have thought it was because the notation is not just for objects.
Using the expanded version of the acronym gives the impression that this specification is in some way entangled with JavaScript. (The fact that Glyn reads "JavaScript Object" as a reference to the string-keyed maps JavaScript started out with is another example for the confusion.)
I feel like anyone who knows about JSON had likely come across our asked about its relationship with its namesake. I don't really think this is something that is needed. I mean, do it if it makes you feel better, but it's not really necessary.
In the RFC series, the expansion is no longer needed, which is a good thing, because the expansion is misleading. This PR adapts the JSONPath specification to this fact. I'm not sure what "this" and "it" are in your message. This PR is not about making anyone of us feel better, it is about improving the document to be less misleading.
I think we are all agreed that merging is fine.
LGTM, thanks.

Revised text:
Abstract JSONPath defines a string syntax for selecting and extracting values  <ins> within a JSON (RFC 8259) value. </ins> 1.  <ins> JSON RFC8259 is a popular representation format for structured data values.  JSONPath defines a string syntax for identifying values within a JSON value. </ins> JSONPath is not intended as a replacement for, but as a more powerful companion to, JSON Pointer RFC6901.  See json-pointer.
Original text:
3.1. A JSONPath query is a string which selects zero or more nodes of a <del> piece of JSON. </del>  A query MUST be encoded using UTF-8.  The grammar for queries given in this document assumes that its UTF-8 form is first decoded into resource depletion and related errors are comparable to 500 type errors.)  3.2. Syntactically, a JSONPath query consists of a root selector ("$"),

Reviewer comments:
Fixes URL
NAME :
It depends. For example, the APIs of some JSONPath implementations take a rich type which represents a valid JSON value. In that case, handling invalid JSON happens before the API is called and is not a concern of the API. But other implementations could have an API which takes a string, which may or may not represent valid JSON. So, to be clear, we probably need some words in the spec which says the spec does not prescribe how invalid JSON is handled. This is better than silence. Or we could require that invalid JSON cannot result in a non-empty nodelist from a JSONPath query.
NAME But "brokenness" would apply to JSON texts, wouldn't it? As NAME noted in (URL), "JSON text is a sequence of characters, an unparsed piece of JSON for interchange, with newlines and backslashes and all that. JSONPath never looks at JSON texts. JSON value is the RFC 8259 term for what JSONPath looks at." The parser would care about "broken" JSON texts, but JSONPath should never see them.
Agree with last two points. The spec describes the application of a JSONPath expression to parsed JSON, so JSON texts are out-of-scope. As NAME says, we should make that explicit.
JSON Schema simply that it operates on the JSON data model. This section covers a range of issues that we've found in our history, including handling whitespace differences, duplicate keys, etc. I think this is a great approach.
Thanks!

Revised text:
3.1. A JSONPath query is a string which selects zero or more nodes of a  <ins> JSON value. </ins> A query MUST be encoded using UTF-8.  The grammar for queries given in this document assumes that its UTF-8 form is first decoded into resource depletion and related errors are comparable to 500 type errors.) <ins> The JSON value the JSONPath query is applied to is, by definition, a valid JSON value.  The parsing of a JSON text into a JSON value and what happens if a JSON text does not represent valid JSON are not defined by this specification. </ins> 3.2. Syntactically, a JSONPath query consists of a root selector ("$"),
Original text:
for each member of the first object with name "n" and value "v", there is a member of the second object with name "n" <del> and value "w" where "v" and "w" yield true when comparsed </del>  using "==", and for each member of the second object with name "n" and value "v", there is a member of the first object with name "n" and <del> value "w" where "v" and "w" yield true when comparsed using </del>  "==". a comparison using the operator "!=" yields true if and only if same type which are both numbers or both strings and which satisfy the comparison: <del> numbers in the I-JSON RFC7493 range of exact values MUST compare using the normal mathematical ordering; one or both numbers outside that range MAY compare using an implementation </del>  specific ordering the empty string compares less than any non-empty string

Reviewer comments:
Fix some nits pointed out by NAME Improve definition of children Unicode Scalar Values are integers Typo fix Ordering of non-integer numbers

Revised text:
for each member of the first object with name "n" and value "v", there is a member of the second object with name "n"  <ins> and value "w" where "v" and "w" yield true when compared </ins> using "==", and for each member of the second object with name "n" and value "v", there is a member of the first object with name "n" and  <ins> value "w" where "v" and "w" yield true when compared using </ins> "==". a comparison using the operator "!=" yields true if and only if 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 interoperate as per I-JSON MAY compare using an implementation </ins> specific ordering the empty string compares less than any non-empty string
Original text:
3.4.7.2.4. The logical AND, OR, and NOT operators have the normal semantics of <del> Boolean algebra and consequently obey these laws (where "P", "Q", and "R" are any expressions with syntax "logical-and-expr", "T" is any expression that yields true, such as "1 == 1", and "F" is any expression that yields false, such as "1 == 0"): </del>  3.4.7.3. with double quotes) in JSON texts. The syntax of Normalized Paths is restricted so that there is one and <del> only one way of representing any given Normalized Path.  Putting this another way, for any two distinct Normalized Paths, a JSON value exists that will yield distinct results when the Normalized Paths are applied to it. </del>  Certain characters are escaped, in one and only one way; all other characters are unescaped.

Reviewer comments:
There were picked up by NAME Improve table 1 Improve comparison examples Link to Boolean laws Make some examples shorter More list selector examples Compress two examples into one Clarify description of Normalized Paths
NAME The section concerning you needs more work, but I'm going to merge this PR with what we have and start a new one to improve that section.
NAME This should do it: URL

Revised text:
3.4.7.2.4. The logical AND, OR, and NOT operators have the normal semantics of  <ins> Boolean algebra and obey its laws (see, for example, BOOLEAN-LAWS). </ins> 3.4.7.3. with double quotes) in JSON texts. The syntax of Normalized Paths is restricted so that there is one and  <ins> only one way of identifying a given node.  Putting this another way, two distinct Normalized Paths are never equivalent to each other: there will always be at least one JSON value that yields distinct results when those paths are applied to it. </ins> Certain characters are escaped, in one and only one way; all other characters are unescaped.
Original text:
escaping when Normalized Paths appear as strings (which are delimited with double quotes) in JSON texts. <del> The syntax of Normalized Paths is restricted so that there is one and only one way of identifying a given node.  Putting this another way, two distinct Normalized Paths are never equivalent to each other: there will always be at least one JSON value that yields distinct results when those paths are applied to it. </del> Certain characters are escaped, in one and only one way; all other characters are unescaped.

Reviewer comments:
The one to one correspondence sentence gives us most of the desired properties. The fact that for distinct Normalized Paths there will always be at least one JSON value which can distinguish the paths is interesting but not crucial. If it's confusing to some people, then it's probably a distraction.
yes ... this is a good minimalistic solution ... thanks

Revised text:
escaping when Normalized Paths appear as strings (which are delimited with double quotes) in JSON texts.  Certain characters are escaped, in one and only one way; all other characters are unescaped.
Original text:
The examples are based on the simple JSON value shown in fig-example- value, representing a bookstore (that also has bicycles). <del> The examples in tbl-example use the expression mechanism to obtain the number of elements in an array, to test for the presence of a member in an object, and to perform numeric comparisons of member values with a constant. </del>  3.

Reviewer comments:
The deleted text referred, erroneously, to an example obtaining the number of elements in an array. It also used the term "expression mechanism" instead of "filter expression". On the whole, it seemed better to slim the text down to the bare minimum.

Revised text:
The examples are based on the simple JSON value shown in fig-example- value, representing a bookstore (that also has bicycles).  <ins> tbl-example shows some JSONPath queries that might be applied to this example and their intended results. </ins> 3.
Original text:
JSONPath expressions are applied to a JSON value, the <del> .  Within the JSONPath expression, the abstract name "$" is used to refer to the </del>  <del> of the argument, i.e., to the argument as a whole. </del>  <del> JSONPath expressions use the </del>  , for example: , for example: <del> to build paths that are input to a JSONPath implementation.  A single path may use a combination of bracket and dot notations. </del>  Dot notation is a shorthand way of writing certain bracket notations.  A wildcard "*" (wildcard) in the expression "[*]" selects all children of an object or an array and in the expression "..[*]" selects all descendants of an object or an array. Filter expressions "?<boolean expr>" select certain children of an object or array as in  tbl-overview provides a quick overview of the JSONPath syntax elements. <del> This document treats the bracket notations as canonical and defines the above shorthands in terms of the canonical bracket notation. </del> 2. This section provides examples of JSONPath expressions.  The examples

Reviewer comments:
This is a stab at addressing one NAME review comments in PR .
NAME If you don't think this PR is going in the right direction, please close it and we'll circle back to the matter later.
The term "current node" is traditionally used with iterating over children of structured nodes in filter selectors. Now it also appears in 3.3 Semantics chapter in a different context: To avoid confusion of readers, we might use a different term there. A good alternative would be "context node", which is also used by XPath in a similar context.
Perhaps a simple solution would be to avoid the use of the term in 3.3 as this term doesn't appear to be used elsewhere.
Please see the simplification in URL

Revised text:
JSONPath expressions are applied to a JSON value, the  <ins> . A JSONPath expression consists of an identifier followed by a series of zero or more segments each of which contains one or more selectors. 1.3.1. The "$" refers to the of the argument, i.e., to the argument as a whole.  Every JSONPath expression begins with the root node identifier. The "@" refers to the </ins>  <ins> in the context of the evaluation of a filter expression (described later). </ins>  <ins> 1.3.2. Segments can use the </ins> , for example: , for example:  <ins> A JSONPath expression may use a combination of bracket and dot notations. </ins> Dot notation is a shorthand way of writing certain bracket notations. <ins> This document treats the bracket notations as canonical and defines various shorthands in terms of bracket notation.  Examples and descriptions use shorthands where convenient. 1.3.3. </ins> A wildcard "*" (wildcard) in the expression "[*]" selects all children of an object or an array and in the expression "..[*]" selects all descendants of an object or an array. Filter expressions "?<boolean expr>" select certain children of an object or array as in <ins> 1.3.4. </ins> tbl-overview provides a quick overview of the JSONPath syntax elements.  2. This section provides examples of JSONPath expressions.  The examples
Original text:
3.8.1. <del> "$["u00b1"]" is normalized into (noise in the table and lack of typewriter font is due to RFCXMLv3 limitations). </del> 4. 4.1.

Reviewer comments:
Fixes URL
Do we intend to replace this with anything? What is its purpose in being here?
The N-1 line also illustrates the point so I think it's probably OK to leave it?
Sorry, I didn't pay attention. The purpose of this example was to show that escaped characters are normalized into their actual equivalents (unless there is a reason not to do so). The messiness is a workaround for xml2rfc bugs. I'm confident we can get these bugs fixed before this is published; otherwise we might indeed want to skip this example.
Why doesn't the example already show that an escaped character is normalised into its actual equivalent ("a")?
It does. Many implementers will however think that this only applies to 95-ASCII characters (there is no reason for thinking that, but it is a highly likely misunderstanding).
The last entry in table 15 is completely incomprehensible and the explanation in the following paragraph doesn't help. Not sure how to work around this within the limitations of xml2rfc but maybe just leave it out, it's implicit in the 2nd-last-line example.
NAME I presume you are referring to with the caption "Normalized Path examples". (Table 15 at is a different one.) I agree the example is a mess and doesn't pull its weight, so I'll submit a PR to delete it.
I think it is useful to have an example that shows characters are not normally escaped, even if they are beyond ASCII.
(By the time this goes by the RFC editor, we may be able to get rid of the useless U+.... stuff added by xml2rfc.)

Revised text:
3.8.1.  4. 4.1.
Original text:
Abstract <del> JSONPath defines a string syntax for selecting and extracting values within a JSON (RFC 8259) value. </del>  1. JSON RFC8259 is a popular representation format for structured data <del> values.  JSONPath defines a string syntax for identifying values within a JSON value. </del>  JSONPath is not intended as a replacement for, but as a more powerful companion to, JSON Pointer RFC6901.  See json-pointer.

Reviewer comments:
This is an attempt to make two sentences in the abstract and introduction less clunky while not jettisoning their precision.
Thanks NAME I see you managed to approve a draft PR - interesting.
Works for me, although one would need to understand that JSON values are nested to understand the abstract. (But we can't start from the creation of the universe.)

Revised text:
Abstract  <ins> JSONPath defines a string syntax for selecting and extracting JSON (RFC 8259) values from a JSON value. </ins> 1. JSON RFC8259 is a popular representation format for structured data  <ins> values.  JSONPath defines a string syntax for selecting and extracting JSON values from a JSON value. </ins> JSONPath is not intended as a replacement for, but as a more powerful companion to, JSON Pointer RFC6901.  See json-pointer.
Original text:
empty nodelist is a valid query result. A segment performs its function on each of the nodes in its input <del> nodelist.  During such a function execution, each such node is referred to as the "current node".  Each of these function executions produces a nodelist, which are then concatenated to produce the result of the segment.  A node may be selected more than once and appears that number of times in the nodelist.  Duplicate nodes are not removed. </del>  A syntactically valid segment MUST NOT produce errors when executing the query.  This means that some operations that might be considered

Reviewer comments:
Fixes URL
I left that in deliberately. We have removed the colliding term and we are now free to use current node () throughout. I will follow up with a PR which does just that. I objected to the term "function" in this context previously. I'll follow up with a PR to delete it, which will leave it free for function extensions.
The term "current node" is traditionally used with iterating over children of structured nodes in filter selectors. Now it also appears in 3.3 Semantics chapter in a different context: To avoid confusion of readers, we might use a different term there. A good alternative would be "context node", which is also used by XPath in a similar context.
Perhaps a simple solution would be to avoid the use of the term in 3.3 as this term doesn't appear to be used elsewhere.
Please see the simplification in URL
Note that there is still an instance of "current node identifier" in table 1. I also note that then English usage of "function" now collides with the term we coin in the function extensions. But the basic change here is right, so I approve.

Revised text:
empty nodelist is a valid query result. A segment performs its function on each of the nodes in its input  <ins> nodelist.  Each of these function executions produces a nodelist, which are then concatenated to produce the result of the segment.  A node may be selected more than once and appears that number of times in the nodelist.  Duplicate nodes are not removed. </ins> A syntactically valid segment MUST NOT produce errors when executing the query.  This means that some operations that might be considered
Original text:
3.5.5.1. <del> The filter selector has the form "?<expr>".  It works via iterating over structured values, i.e. arrays and objects. </del>  <del> During the iteration process each array element or object member is visited and its value -- accessible via symbol "@" -- or one of its descendants -- uniquely defined by a relative path -- is tested against a boolean expression "boolean-expr". The current item is selected if and only if the boolean expression yields true. </del>  Paths in filter expressions are Singular Paths, each of which selects at most one node.  Parentheses MAY be used within "boolean-expr" for grouping. Comparisons are restricted to Singular Path values and primitive nodelist is not stipulated, since JSON objects are unordered. Children of an array appear in array order in the resultant nodelist. <del> A relative path, beginning with "@", refers to the current array element or member value as the filter selector iterates over the array or object. </del> 3.5.5.2.1. A singular path by itself in a Boolean context is an existence test

Reviewer comments:
There may be some more shake-out as filter semantics are scattered through the syntax section. We may need to live with this because it makes more sense to talk about semantics in the context of each particular piece of syntax. But let's use the current PR just to use the current node term consistently.

Revised text:
3.5.5.1.  <ins> The filter selector has the form "?<expr>".  It iterates over structured values, i.e., arrays and objects. </ins>  <ins> During the iteration process the node of each array element or object member being visited is known as the current node.  A boolean expression, usually involving the current node, is evaluated and the current node is selected if and only if the expression yields true. </ins> Paths in filter expressions are Singular Paths, each of which selects at most one node. <ins> The current node is accessible via the current node identifier "@". </ins> Parentheses MAY be used within "boolean-expr" for grouping. Comparisons are restricted to Singular Path values and primitive nodelist is not stipulated, since JSON objects are unordered. Children of an array appear in array order in the resultant nodelist.  3.5.5.2.1. A singular path by itself in a Boolean context is an existence test
Original text:
3.5.4.2.1. <del> This section is non-normative. </del>  Array slicing is inspired by the behavior of the "Array.prototype.slice" method of the JavaScript language as defined

Reviewer comments:
Non-normative may be a better option, throughout, because surely normative sections are informative too? NAME WDYT?
Given we use Informative for the non-normative references, I guess we should do the same throughout. Hopefully no-one will misunderstand...

Revised text:
3.5.4.2.1.  <ins> This section is informative. </ins> Array slicing is inspired by the behavior of the "Array.prototype.slice" method of the JavaScript language as defined