jiebi/TextFlow huggingface dataset:
Original text:
This section is informative. <del> A JSONPath expression is applied to a JSON value, the .  The output is a nodelist. </del>  A JSONPath expression consists of an identifier followed by a series of zero or more segments each of which contains one or more 1.4.1. <del> The "$" refers to the of the argument, i.e., to the argument as a whole.  Every JSONPath expression begins with the root node identifier. </del>  <del> The "@" refers to the in the context of the evaluation of a filter expression (described later). </del>  1.4.2. value). The query is a root identifier followed by a sequence of zero or more <del> , each of which is applied to the result of the previous root </del>  identifier or segment and provides input to the next segment.  These results and inputs take the form of a nodelist.

Reviewer comments:
This is currently done inconsistently and doesn't add much value. Instead, define terms in the Terminology section. Reviewers please note: is not modified. This avoids a clash with URL which deletes the term.
Let's wait until lands before sorting this PR out. Meanwhile, rebased on main and kept one of the italicisations which was previously removed.
I've reinstated the other italics which NAME favoured.

Revised text:
This section is informative.  <ins> A JSONPath expression is applied to a JSON value, known as the argument.  The output is a nodelist. </ins> A JSONPath expression consists of an identifier followed by a series of zero or more segments each of which contains one or more 1.4.1.  <ins> The root node identifier "$" refers to the root node of the argument, i.e., to the argument as a whole.  Every JSONPath expression begins with the root node identifier. </ins>  <ins> The current node identifier "@" refers to the current node in the context of the evaluation of a filter expression (described later). </ins> 1.4.2. value). The query is a root identifier followed by a sequence of zero or more  <ins> segments, each of which is applied to the result of the previous root </ins> identifier or segment and provides input to the next segment.  These results and inputs take the form of a nodelist.
Original text:
"Value" is an abstraction of a primitive value.  "OptionalValue" is an abstraction of a primitive value that may also be absent. If it occurs as a "filter-path" in an existence test, the function is defined to have result type "OptionalNodes" or one of its  subtypes. If it occurs as a "comparable" in a comparison, the function is

Reviewer comments:
Now we have switched to using function extensions for regexp filter matches, the current syntax requires the result to be compared against a boolean, as shown in this example from PR 330: This is consistent with the following statement in the "Existence Tests" section of the spec: If we wanted the following syntax to act as a regexp test: we would have to allow a function expression (returning a boolean result) to be treated as a (rather than an or a ). This would require (a) considerable rework of filter selectors and (b) making a special case of functions which return booleans. To be clear: I am not in favour of such a change. The reason for raising this issue was so that it doesn't come as a surprise to the WG. Thanks to NAME who spotted it when reviewing some draft input to PR 330.
This was fixed by the above PR.
Excellent!

Revised text:
"Value" is an abstraction of a primitive value. <ins> "Boolean" is an abstraction of a primitive value that is either "true" or "false". </ins> "OptionalValue" is an abstraction of a primitive value that may also be absent. If it occurs as a "filter-path" in an existence test, the function is defined to have result type "OptionalNodes" or one of its <ins> subtypes, or to have result type "OptionalBoolean" or one of its </ins> subtypes. If it occurs as a "comparable" in a comparison, the function is
Original text:
This document models the result of applying a query to the argument as a nodelist (a list of nodes). <del> So nodes are the selectable parts of the argument.  The only parts of an object that can be selected by a query are the member values. Member names and members (name/value pairs) cannot be selected.  So </del>  member values have nodes, but members and member names do not. Similarly, member values are children of an object, but members and member names are not. 2.1. <del> A JSONPath expression is a string which, when applied to a JSON value, the </del>  , selects zero or more nodes of the argument and outputs these nodes as a nodelist. In this document, the semantics of a JSONPath query define the required results and do not prescribe the internal workings of an <del> implementation. </del>  The semantics are that a valid query is executed against a value, the A "dot-member-name-shorthand" of the form ".<member-name>" is shorthand for "['<member-name>']", but can only be used with member names that are composed of certain characters.  Thus, for example, <del> "$.foo.bar" is shorthand for "$['foo']['bar']" (and not for </del>  "$['foo.bar']"). 2.7.1.2.

Reviewer comments:
Signed-off-by: Tim Bray Nothing fancy here, just like the title says.
LGTM, thanks.

Revised text:
This document models the result of applying a query to the argument as a nodelist (a list of nodes).  <ins> Nodes are the selectable parts of the argument.  The only parts of an object that can be selected by a query are the member values.  Member names and members (name/value pairs) cannot be selected.  Thus, </ins> member values have nodes, but members and member names do not. Similarly, member values are children of an object, but members and member names are not. 2.1.  <ins> A JSONPath is a string which, when applied to a JSON value, the </ins> , selects zero or more nodes of the argument and outputs these nodes as a nodelist. In this document, the semantics of a JSONPath query define the required results and do not prescribe the internal workings of an  <ins> implementation.  This document may describe semantics in a procedural step-by-step fashion, but such descriptions are normative only in the sense that any implementation MUST produce an identical result, but not in the sense that implementors are required to use the same algorithms. </ins> The semantics are that a valid query is executed against a value, the A "dot-member-name-shorthand" of the form ".<member-name>" is shorthand for "['<member-name>']", but can only be used with member names that are composed of certain characters.  Thus, for example,  <ins> "$.foo.bar" is shorthand for "$['foo']['bar']" (but not for </ins> "$['foo.bar']"). 2.7.1.2.
Original text:
subsections, JSONPath defines an extension point that can be used to add filter expression functionality: "Function Extensions".  A function extension defines a registered name (see iana-fnex) that can be applied to a sequence of zero or more arguments, producing a result.

Reviewer comments:
Add note that using the extension point mechanism doesn't imply the "function extensions" to be non-mandatory.

Revised text:
subsections, JSONPath defines an extension point that can be used to add filter expression functionality: "Function Extensions". <ins> This section defines the extension point as well as four function extensions that use this extension point.  While these mechanisms are designed to use the extension point, they are an integral part of the JSONPath specification and are mandatory to implement. </ins> A function extension defines a registered name (see iana-fnex) that can be applied to a sequence of zero or more arguments, producing a result.
Original text:
"true" or "false". "OptionalValue" is an abstraction of a primitive value that may <del> also be absent. "Absent" is an abstraction of an empty nodelist. </del>  "OptionalNodes" is an abstraction of a "filter-path" (which appears in an existence test or as a function argument).

Reviewer comments:
Remove single-valued type "Absent". This is not useful as a function signature type (parameter or result).
I'm looking at 2.6.1 and wondering if it would be meaningful for a function to have a result type of . How could such a function be used in a filter? If it is the case that this doesn't make sense, that should probably be noted in the text.
By "absent" do you mean "no return value," like a function in C? If so, what would be the point? The usefulness of functions is that they perform calculations on inputs and provide a result.
Indeed, the clarification should be that not all types that make up the type hierarchy are useful as return types. (Which does not mean they need to be outlawed -- they are just not useful.)
No. is a type with one instance ().
I can just about conceive of a logging function that doesn't need to return a value returning type . It could be used in a filter expression like this . I'm not suggesting that's a good idea, but it could be done.
That has no impact on the output of the query, though. Why would one include such a thing? Logging is an implementation/application concern. What? I'm asking about the meaning of . How is it used? What's it's purpose? It doesn't appear in the spec anywhere, so why even ask the question?
2023-01-10 Interim: Remove Absent type.

Revised text:
"true" or "false". "OptionalValue" is an abstraction of a primitive value that may  <ins> alternatively be absent ("Nothing"). </ins> "OptionalNodes" is an abstraction of a "filter-path" (which appears in an existence test or as a function argument).
Original text:
Its only argument is a nodelist.  The result is a value, an unsigned integer, that gives the number of nodes in the nodelist.  Note that <del> there is no deduplication of the nodelist. [dedup] </del>  2.6.5. Other attacks can target the behavior of underlying technologies such as UTF-8 (see RFC3629) and the Unicode character set. <del> Editorial Comments [dedup] Well, that can be discussed. </del>

Reviewer comments:
Delete the editor's note as »Note that there is no deduplication of the nodelist.« is now the agreed behavior.
As currently specified, there is no deduplication of nodes input to the count() function extension. But the spec contains a placeholder suggesting discussion of deduplication. This issue is for that discussion. This issue is related to URL because if function extensions do not have access to node location, then it would not be possible to deduplicate on node identity, only potentially on value.
2023-01-10 Interim: Remove the editor's note now.

Revised text:
Its only argument is a nodelist.  The result is a value, an unsigned integer, that gives the number of nodes in the nodelist.  Note that  <ins> there is no deduplication of the nodelist. </ins> 2.6.5. Other attacks can target the behavior of underlying technologies such as UTF-8 (see RFC3629) and the Unicode character set.
Original text:
If the argument value is an object, the result is the number of members in the object. <del> For any other argument value, the result is one. </del>  2.6.4.

Reviewer comments:
For , the spec defines Why return 1? That's a possible value for to return for valid inputs. Wouldn't it make sense to return a value that can't be returned by a valid input, like -1? Currently, this returns the both objects in the array, which is counter-intuitive. The length of the property in is nonsensical because it doesn't contain an property.
Well, I picked this hoping people would notice this... We have two different cases that probably also need different answers. The one the text addresses: A non-container, non-string value, e.g., length(3) I think I can argue that 1 is a good value for that. The one the text does not address: An empty nodelist (Nothing). 1 is definitely not a good value for that. Nothing speaks for -1 except FORTRAN-era conventions. I think we want to be able to return Nothing here.
I disagree. I don't think the "length" of is 1. I think it's nonsensical. Numbers, booleans, nulls, and (really all that's left) don't have a "length." (We've also decided that we don't do any kind of type coersion, so interpreting as is invalid.) I'm happy with this.
I'd be comfortable with returning .
LGTM, thanks.

Revised text:
If the argument value is an object, the result is the number of members in the object.  <ins> For any other argument value, the result is "Nothing". </ins> 2.6.4.
Original text:
1.4.1. The root node identifier "$" refers to the root node of the argument, <del> i.e., to the argument as a whole.  Every JSONPath expression begins with the root node identifier. </del>  The current node identifier "@" refers to the current node in the context of the evaluation of a filter expression (described later). 2.4.1. <del> Every JSONPath query MUST begin with the root identifier "$". </del>  2.4.2.

Reviewer comments:
Fixes URL
Section 1.4 says: >A JSONPath expression consists of an identifier followed by a series of zero or more segments each of which contains one or more selectors. So this includes relative paths (starting with ). However, section 1.4.1 contradicts this: Similarly, section 2.4 says: >Every JSONPath query MUST begin with the root identifier . (Remember that, according to our terminology, "query" is a short name for a JSONPath expression.) A possible solution is for sections 1.4.1 and 2.4 to talk about JSONPath expressions/queries which do not appear inside a filter expression.

Revised text:
1.4.1. The root node identifier "$" refers to the root node of the argument,  <ins> i.e., to the argument as a whole. </ins> The current node identifier "@" refers to the current node in the context of the evaluation of a filter expression (described later). 2.4.1.  <ins> Every JSONPath query (except those inside filter expressions, see filter-selector) MUST begin with the root identifier "$". </ins> 2.4.2.
Original text:
Each entry in the registry must include: <del> Initial entries in this sub-registry are as listed in pre-reg: </del>  4.

Reviewer comments:
Fixes URL NAME Any advice on how to format the table so that line length warnings are not produced (by or )?
(1) we could shorten unwieldy monsters such as or (2) we could strip the columns "Change Controller" and "Reference" and just add to the caption that the column value for all of these are "IESG" and "Section 2.6 of RFCthis".
I made a commit for (2). I'd still like to tame the type names as well..
The Function Extensions section of the IANA Considerations section should use the defined type system terminology rather than talking about "kinds", "values", and "nodelists".

Revised text:
Each entry in the registry must include:  <ins> Initial entries in this sub-registry are as listed in pre-reg; the Column "Change Controller" always has the value "IESG" and the column "Reference" always has the value "fnex of RFCthis": </ins> 4.
Original text:
a comparison using the operator "==" yields true if and only if the comparison is between: <del> equal primitive values, </del>  equal arrays, that is arrays of the same length where each element of the first array is equal to the corresponding

Reviewer comments:
Fixes URL
The ABNF is not currently subject to the I-JSON range restriction that applies to array indices and array slice parameters, but I don't see why it shouldn't be.
I don't understand -- the grammar cannot express this restriction. Indices and slice parameters are integers, not numbers, BTW.
I was thinking of the integer subset of . It seems strange to have to cope with arbitrary precision integers there, but not for array indices and slices.
As for the grammar expressing the restriction, this is a question of validity rather than well-formedness.
Ah, so this would be a text fix.
Indeed. Sorry for the ABNF red herring. I was trying to be precise about which "number" I was talking about.
I guess we'll have to worry about decimal as well as integers in , for consistency. I wonder if there's a suitable precedent like the I-JSON range?
Hmm, is not really discussed in the unnumbered (argh) section "comparisons". (There is text for .)
How about this text?
(and in case anyone thinks we could get away with comparing the string forms of the numbers, remember scientific notation .)
Oh, I see now. We should mention the I-JSON restrictions for numbers, in the comparison section. That seems like a reasonable way to fix this issue.
the complement of "both interoperate" is "at least one doesn't interoperate"...

Revised text:
a comparison using the operator "==" yields true if and only if the comparison is between:  <ins> numbers expected to interoperate as per RFC7493 that compare equal using normal mathematical equality, numbers at least one of which is not expected to interoperate as per I-JSON, where the numbers compare equal using an implementation specific equality, equal primitive values which are not numbers, </ins> equal arrays, that is arrays of the same length where each element of the first array is equal to the corresponding
Original text:
of a value and make that available for further processing in the filter expression: <del> Its only argument is a value (possibly taken from a singular path as in the example above).  The result also is a value, an unsigned integer. </del>  If the argument value is a string, the result is the number of Unicode scalar values in the string. entirety of, see search below) a given string matches a given regular expression, which is in I-D.draft-ietf-jsonpath-iregexp form. <del> Its first argument is a string that is matched against the iregexp contained in the string that is the second argument.  The result is "true" if the string matches the iregexp and "false" otherwise. </del>  The result is "Nothing" if the first argument is not a string or the second argument is not a string conforming to I-D.draft-ietf- given string contains a substring that matches a given regular expression, which is in I-D.draft-ietf-jsonpath-iregexp form. <del> Its first argument is a string that is searched for at least one substring that matches the iregexp contained in the string that is the second argument.  The result is "true" if such a substring exists, "false" otherwise. </del>  The result is "Nothing" if the first argument is not a string or the second argument is not a string conforming to I-D.draft-ietf-

Reviewer comments:
Fixes URL
NAME I pushed cb1cf124ab to clarify optional arguments.
NAME raised this in a PR review.
I think the answer is "yes" because that allows the function to be used on a Singular Path rather than on just a literal.
Yes. I would expect any function that can take a path must allow any value.
That should be enough to remove this double-take.

Revised text:
of a value and make that available for further processing in the filter expression:  <ins> Its only argument is an optional value (possibly taken from a singular path as in the example above).  The result also is an optional value, an unsigned integer. </ins> If the argument value is a string, the result is the number of Unicode scalar values in the string. entirety of, see search below) a given string matches a given regular expression, which is in I-D.draft-ietf-jsonpath-iregexp form.  <ins> Its first argument is an optional string that is matched against the iregexp contained in the string that is the second argument.  The result is "true" if the string matches the iregexp and "false" otherwise. </ins> The result is "Nothing" if the first argument is not a string or the second argument is not a string conforming to I-D.draft-ietf- given string contains a substring that matches a given regular expression, which is in I-D.draft-ietf-jsonpath-iregexp form.  <ins> Its first argument is an optional string that is searched for at least one substring that matches the iregexp contained in the string that is the second argument.  The result is "true" if such a substring exists, "false" otherwise. </ins> The result is "Nothing" if the first argument is not a string or the second argument is not a string conforming to I-D.draft-ietf-
Original text:
"[{"j": 4}, {"k": 6}]" must appear before "{"j": 4}" and "{"k": 6}", <del> "{"j": 4}" must appear before "4", and </del>  <del> "{"k": 6}" must appear before "6". </del>  The example above with the query "$.o..[*, *]" shows that a selector may produce nodelists in distinct orders each time it appears in the

Reviewer comments:
URL
This change looks good, thank you. I have one more, though (looking more closely at the diagnostics): I don't think the "Alternative result" can be generated, as outside arrays come before inside arrays.
Yes, nodes are visited before their descendants. Fixed in 1b85e02c7a5e60ba87ab1c455502c66816327f9d.
URL

Revised text:
"[{"j": 4}, {"k": 6}]" must appear before "{"j": 4}" and "{"k": 6}",  <ins> "{"j": 4}" must appear before "{"k": 6}", </ins>  <ins> "{"k": 6}" must appear before "4", and "4" must appear before "6". </ins> The example above with the query "$.o..[*, *]" shows that a selector may produce nodelists in distinct orders each time it appears in the
Original text:
"LogicalType" is an abstraction of the result of a "logical-expr". Its two instances, "LogicalTrue" and "LogicalFalse", are not <del> related to the JSON literals "true" and "false" and have no </del>  syntactical representation in JSONPath. "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 syntactical representation in JSONPath. </del>  The abstract instances above can be obtained from the concrete representations in tbl-typerep.

Reviewer comments:
There are some syntactical representations, e.g.: LogicalTrue can be represented by (1==1). LogicalFalse can be represented by (1==0). Nothing can be represented by a query that always returns the empty nodelist, such as $[?1==0]. But these are somewhat circuitous rather than direct. See URL
NAME I also considered deleting the statements about there being no (direct) syntactical representation of the values of certain types because I'm not sure they add much. The text in this PR adds an air of mystery - what are "direct syntactical representations"? WDYT?
I'm not sure how "direct" clarifies "syntactical representation." Either something can be represented in the syntax or it can't. Merge if you like.
This is obviously an improvement. We also could say "literals", but then we would assume knowledge about this programming language construct. So I think this should simply be merged.

Revised text:
"LogicalType" is an abstraction of the result of a "logical-expr". Its two instances, "LogicalTrue" and "LogicalFalse", are not  <ins> related to the JSON literals "true" and "false" and have no direct </ins> syntactical representation in JSONPath. "NodesType" is an abstraction of a "filter-path" (which appears in a test expression or as a function argument).  Members of  <ins> "NodesType" have no direct syntactical representation in JSONPath. </ins> The abstract instances above can be obtained from the concrete representations in tbl-typerep.