jiebi/TextFlow huggingface dataset:
Original text:
2.3.2.2. <del> A "wildcard" selector selects the nodes of all children of an object or array.  The order in which the children of an object appear in the </del>  resultant nodelist is not stipulated, since JSON objects are unordered.  Children of an array appear in array order in the resultant nodelist. <del> The "wildcard" selector selects nothing from a primitive JSON value </del>  (that is, a number, a string, "true", "false", or "null"). 2.3.2.3.

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:
2.3.2.2.  <ins> A wildcard selector selects the nodes of all children of an object or array.  The order in which the children of an object appear in the </ins> resultant nodelist is not stipulated, since JSON objects are unordered.  Children of an array appear in array order in the resultant nodelist.  <ins> The wildcard selector selects nothing from a primitive JSON value </ins> (that is, a number, a string, "true", "false", or "null"). 2.3.2.3.
Original text:
Queries: <del> The examples in tbl-wild show the "wildcard" selector in use by a child segment: </del>  The example above with the query "$.o[*, *]" shows that the wildcard selector may produce nodelists in distinct orders each time it

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:
Queries:  <ins> The examples in tbl-wild show the wildcard selector in use by a child segment: </ins> The example above with the query "$.o[*, *]" shows that the wildcard selector may produce nodelists in distinct orders each time it
Original text:
If the nodelist is empty, the conversion result is "LogicalFalse". <del> Extraction of a value from a nodelist can be performed in several ways, so an implicit conversion from "NodesType" to "ValueType" may be surprising and has therefore not been defined.  A function expression with a declared type of "NodesType" can indirectly be used as an argument for a parameter of declared type "ValueType" by wrapping the expression in a call to a function extension such as "value" (see value). </del>  The well-typedness of function expressions can now be defined in terms of this type system.

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:
If the nodelist is empty, the conversion result is "LogicalFalse".  <ins> Notes: Extraction of a value from a nodelist can be performed in several ways, so an implicit conversion from "NodesType" to "ValueType" may be surprising and has therefore not been defined. A function expression with a declared type of "NodesType" can indirectly be used as an argument for a parameter of declared type "ValueType" by wrapping the expression in a call to a function extension, such as "value()" (see value), that takes a parameter of type "NodesType" and returns a result of type "ValueType". </ins> The well-typedness of function expressions can now be defined in terms of this type system.
Original text:
2.4.4. <del> The "length" function extension provides a way to compute the length of a value and make that available for further processing in the filter expression: </del>  Its only argument is an instance of "ValueType" (possibly taken from a singular query, as in the example above).  The result also is an

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:
2.4.4.  <ins> The "length()" function extension provides a way to compute the length of a value and make that available for further processing in the filter expression: </ins> Its only argument is an instance of "ValueType" (possibly taken from a singular query, as in the example above).  The result also is an
Original text:
2.4.5. <del> The "count" function extension provides a way to obtain the number of nodes in a nodelist and make that available for further processing in the filter expression: </del>  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

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:
2.4.5.  <ins> The "count()" function extension provides a way to obtain the number of nodes in a nodelist and make that available for further processing in the filter expression: </ins> 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
Original text:
2.4.6. <del> The "match" function extension provides a way to check whether (the </del>  entirety of, see search below) a given string matches a given regular expression, which is in I-D.draft-ietf-jsonpath-iregexp form.

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:
2.4.6.  <ins> The "match()" function extension provides a way to check whether (the </ins> entirety of, see search below) a given string matches a given regular expression, which is in I-D.draft-ietf-jsonpath-iregexp form.
Original text:
2.4.7. <del> The "search" function extension provides a way to check whether a </del>  given string contains a substring that matches a given regular expression, which is in I-D.draft-ietf-jsonpath-iregexp form.

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:
2.4.7.  <ins> The "search()" function extension provides a way to check whether a </ins> given string contains a substring that matches a given regular expression, which is in I-D.draft-ietf-jsonpath-iregexp form.
Original text:
2.4.8. <del> The "value" function extension provides a way to convert an instance of "NodesType" to a value and make that available for further processing in the filter expression: </del>  Its only argument is an instance of "NodesType" (possibly taken from a "filter-query", as in the example above).  The result is an

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:
2.4.8.  <ins> The "value()" function extension provides a way to convert an instance of "NodesType" to a value and make that available for further processing in the filter expression: </ins> Its only argument is an instance of "NodesType" (possibly taken from a "filter-query", as in the example above).  The result is an
Original text:
result is "Nothing". 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. 2.4.9.

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:
result is "Nothing". 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. 2.4.9.
Original text:
If an endpoint receives an ADDRESS_REQUEST capsule that contains zero Requested Addresses, it MUST abort the IP proxying request stream.  4.7.3. The ROUTE_ADVERTISEMENT capsule (see iana-types for the value of the

Reviewer comments:
I'm going to guess that order is not significant. But imagine that an endpoint would only honor a request for N addresses but the requester asks for N+Y. The endpoint has to pick a subset somehow.
What do you mean by "is the list ... significant"? I don't understand the comment about subsetting either --- if you ask for N+Y addresses and get back only N, you have N usable addresses (ranges)
How does the other end decide the which N to pick? Without declaring if the request order is significant, then there can be no expectations of behaviour and we might find interop problems if assumptions don't align.
If you request, say, 4 specific addresses, and the other side can satisfy 3 of the requests because they're still available, it will include those 3. It's implementation-defined it if wants to provide a 4th address that is not the one you requested, or NAK it. However at no point in time was order significant --- you asked for all of these addresses, not any of these addresses.
Friendly amendment: it may include those 3. It could also choose to only assign one, or a different address entirely if the implementation was so inclined.
You are pedantically correct :). I was trying to give a specific worked example.
This design seems reasonable. It might help to state clearly somewhere that the value of the request ID has no significance other than as a unique handle, and that the ordering of and in a single capsule has no significance. This is in contrast to the ROUTE_ADVERTISEMENT where the ordering of things is very significant.
That's a good suggestion Lucas.
My intention when writing this was for the order in the lists to not carry semantics, and similarly for the request ID to only exist for unicity. We should spell that out clearly. One thing we could do however, is saying that request IDs in ADDRESS_REQUEST MUST be increasing, to make duplicate detection easier on the receiver. If we do it, it adds a constraint on the sender and means that the receiver will check, while if we don't add the constraint then receivers won't bother to check. Any thoughts on this point?
I have no strong feeling about the potential to add such rules.
NAME can you propose text here?

Revised text:
If an endpoint receives an ADDRESS_REQUEST capsule that contains zero Requested Addresses, it MUST abort the IP proxying request stream. <ins> Note that the ordering of Requested Addresses does not carry any semantics.  Similarly, the Request ID is only meant as a unique identifier, it does not convey any priority or importance. </ins> 4.7.3. The ROUTE_ADVERTISEMENT capsule (see iana-types for the value of the
Original text:
meet these requirements, it MUST abort the IP proxying request stream.  5. The mechanism for proxying IP in HTTP defined in this document allows

Reviewer comments:
Say for example that A and B have the same IP Version and they have the same or overlapping Start IP Address / End IP Address ranges. A's IP Protocol is zero (the wildcard) whereas B's is non-zero. That causes a weird kind of overlap even though all the requirements are followed. Is it worth disallowing in the spec?
Earlier in this section, the version is defined as such: I think then this is OK, since zeros aren't allowed in route advertisements. NAME that sound OK?
The IP Verson cannot be zero in the ROUTEADVERTISEMENT, but the IP Protocol can: The following ROUTEADVERTISEMENT follows the requirements (the IP Protocol of A is lower than the IP Protocol of B), yet there is an overlap:
Oh, I see, I misread. I do think that it makes sense to put the wildcard first — so 0 shows up before others. And then the more specific protocol rules can potentially have different ranges. I still think this is acceptable to leave as-is.

Revised text:
meet these requirements, it MUST abort the IP proxying request stream. <ins> Since setting the IP protocol to zero indicates all protocols are allowed, the requirements above make it possible for two routes to overlap when one has IP protocol set to zero and the other set to non-zero.  Endpoints MUST not send a ROUTE_ADVERTISEMENT capsule with routes that overlap in such a way.  Validating this requirement is OPTIONAL, but if an endpoint detects the violation, it MUST abort the IP proxying request stream. </ins> 5. The mechanism for proxying IP in HTTP defined in this document allows
Original text:
of the destinations included in the scope, then the IP proxy can immediately fail the request.  4.7. This document defines multiple new capsule types that allow endpoints

Reviewer comments:
From Vinny Parla on the :
I don't think we need to make normative changes to the protocol, but adding a note for implementers that they might want to treat extension headers differently that other IP protocols sounds like a good change. Some additional review comments from an internal review that I wanted to share with you. Section 4.6 has a minor issue as the IANA registry mixes IPv6 extension header with layer-4 headers. It should also specify the use of RFC 5952 for representing IPv6 addresses. However, this can be ignored for now. Section 4.7.1 unsure whether "IP Version" field is useful as it can be derived from "IP Address" length/notation, also not critical but perhaps this would reduce unnecessary information. There is also a minimum 68-byte MTU for IPv4 ;-) - not sure that is important, but wanted to share. The recursive DNS server info (found in RA and DHCP), is not present. Was this an intentional decision or perhaps something that was not considered for some reason? There is no discussion of link-local addresses / ULA (I would expect both end of the 'tunnel' to have link-local addresses), or link-local multicast (e.g., ff02::1). Or perhaps the IP proxy send an IPv6 RA ? or should be prevented from sending one ? Should IP proxy reply to ff02::2 (all link-local routers), ... -Vinny

Revised text:
of the destinations included in the scope, then the IP proxy can immediately fail the request. <ins> Note that IP protocol numbers represent both upper layers (as defined in IPv6, examples include TCP and UDP) and IPv6 extension headers (as defined in IPv6, examples include Fragment and Options headers).  IP proxies MAY reject requests to scope to protocol numbers that are used for extension headers.  Upon receiving packets, implementations that support scoping by IP protocol number MUST walk the chain of extensions to find the matching IP protocol number. </ins> 4.7. This document defines multiple new capsule types that allow endpoints