jiebi/CodeConvo huggingface dataset:
Code change:
The index selector (but not the index wildcard selector) selects no elements from non-arrays. See URL for background.
This seems implicit since JSON objects cannot be numerically accessed.
Yes, but making it explicit is clearer.
This looks okay, and it aligns the text with the previous paragraph.

Related discussion:
text: only if that object has a member with that name.  Nothing is selected from a value that is not a object. <del> Array indexing via "element-index" is a way of selecting a particular array element using a zero-based index.  For example, selector "[0]" selects the first and selector "[4]" the fifth element of a sufficiently long array. </del> <ins> The "index-selector" applied with an "element-index" to an array selects an array element using a zero-based index.  For example, selector "[0]" selects the first and selector "[4]" the fifth element of a sufficiently long array.  Nothing is selected, and it is not an error, if the index lies outside the range of the array.  Nothing is selected from a value that is not an array. </ins> A negative "element-index" counts from the array end.  For example, selector "[-1]" selects the last and selector "[-2]" selects the
Code change:
The index selector (but not the index wildcard selector) selects no elements from non-arrays. See URL for background.
This seems implicit since JSON objects cannot be numerically accessed.
Yes, but making it explicit is clearer.
This looks okay, and it aligns the text with the previous paragraph.

Related discussion:
text: of the selector entries in the list and yields the concatenation of the lists (in the order of the selector entries) of nodes selected by the selector entries.  Note that any node selected in more than one <del> of the selector entries is kept as many times in the node list. </del> <ins> of the selector entries is kept as many times in the nodelist. </ins> To be valid, integer values in the "element-index" and "slice-index" components MUST be in the I-JSON range of exact values, see synsem-
Code change:
Avoid the term indexing, so we don't need to worry about whether it applies only to arrays or to arrays and objects.

Related discussion:
text: A syntactically valid segment MUST NOT produce errors when executing the query.  This means that some operations that might be considered <del> erroneous, such as indexing beyond the end of an array, simply result in fewer nodes being selected. </del> <ins> erroneous, such as using an index lying outside the range of an array, simply result in fewer nodes being selected. </ins> Consider this example.  With the argument "{"a":[{"b":0},{"b":1},{"c":2}]}", the query "$.a[*].b" selects the
Code change:
Avoid the term indexing, so we don't need to worry about whether it applies only to arrays or to arrays and objects.

Related discussion:
text: 2.5.3.2. <del> The "index-selector" applied to an array selects an array element using a zero-based index.  For example, the selector "0" selects the first and the selector "4" selects the fifth element of a </del> <ins> A non-negative "index-selector" applied to an array selects an array element using a zero-based index.  For example, the selector "0" selects the first and the selector "4" selects the fifth element of a </ins> sufficiently long array.  Nothing is selected, and it is not an error, if the index lies outside the range of the array.  Nothing is selected from a value that is not an array.
Code change:
Avoid the term indexing, so we don't need to worry about whether it applies only to arrays or to arrays and objects.

Related discussion:
text: as slice bounds and must first be normalized.  Normalization for this purpose is defined as: <del> The result of the array indexing expression "i" applied to an array of length "len" is defined to be the result of the array slicing </del> <ins> The result of the array index expression "i" applied to an array of length "len" is defined to be the result of the array slicing </ins> expression "Normalize(i, len):Normalize(i, len)+1:1". Slice expression parameters "start" and "end" are used to derive
Code change:
Avoid the term indexing, so we don't need to worry about whether it applies only to arrays or to arrays and objects.

Related discussion:
text: the lower bound and which is the upper bound: The slice expression selects elements with indices between the lower <del> and upper bounds.  In the following pseudocode, the "a(i)" construct expresses the 0-based indexing operation on the underlying array. </del> <ins> and upper bounds.  In the following pseudocode, "a(i)" is the "i+1"th element of the array "a" (i.e., "a(0)" is the first element, "a(1)" the second, and so forth). </ins> When "step = 0", no elements are selected and the result array is empty.
Code change:
I like this structure. We might come up with more validity requirements, so we may want to keep this even if =~ goes away (which is pretty much what we decided last week).

Related discussion:
text: .  A string is a well-formed JSONPath query if it conforms to the ABNF syntax in this document.  A well-formed JSONPath query is valid <del> if it also fulfills all semantic requirements posed by this document. </del> <ins> if it also fulfills all semantic requirements posed by this document, which are: </ins> <del> To be valid, integer numbers in the JSONPath query that are relevant to the JSONPath processing (e.g., index values and steps) MUST be within the range of exact values defined in I-JSON RFC7493, namely within the interval [-(2 </del> <ins> Integer numbers in the JSONPath query that are relevant to the JSONPath processing (e.g., index values and steps) MUST be within the range of exact values defined in I-JSON RFC7493, namely within the interval [-(2 </ins> <del> )+1, (2 </del> <ins> )+1, (2 </ins> <del> )-1]). </del> <ins> )-1]. </ins> <del> To be valid, strings on the right-hand side of the "=~" regex matching operator need to conform to I-D.draft-ietf-jsonpath-iregexp. </del> <ins> Strings on the right-hand side of the "=~" regex matching operator MUST conform to I-D.draft-ietf-jsonpath-iregexp. </ins> The well-formedness and the validity of JSONPath queries are independent of the JSON value the query is applied to; no further
Code change:
Add pair of surrogate escapes to note on string format.
LGTM, thanks. Just one editorial suggestion.

Related discussion:
text: Note: "double-quoted" strings follow the JSON string syntax (RFC8259); "single-quoted" strings follow an analogous pattern <del> (syntax-index). </del> <ins> (syntax-index).  No attempt was made to improve on this syntax, so characters with scalar values above 0x10000, such as U+0026 U+0023 U+0031 U+0032 U+0039 U+0033 U+0030 U+0030 U+003B ("&#129300;", AMPERSAND, NUMBER SIGN, DIGIT ONE, DIGIT TWO, DIGIT NINE, DIGIT THREE, DIGIT ZERO, DIGIT ZERO, SEMICOLON), need to be represented by a pair of surrogate escapes (""uD83EuDD14"" in this case). </ins> 2.5.1.2.
Code change:
E.g.,
I propose a slightly more compact naming of ABNF of - and -segment, which should be more consistent between them two. is well known from LaTeX and means or there.
above is wrong (and so it is in the current spec). It needs to read ... to not allow triple dot ( :-)
NAME Wouldn't dotdot-wildcard etc. be less cryptic?
Here are some quibbles with the current ABNF (prior to PR being merged) which we can sort out after The Great Renaming:
Yes, yes. See. Fixed in I like the way this looks like now. Maybe I don't understand; can you elaborate? Fixed this (and following) in Removed in To be fixed in overall overhaul, next Yes! To be fixed in overall overhaul, next To be fixed in overall overhaul, next Fixed in Discuss this in its own issue, I'd say. Fixed in It certainly does not -- it is the subset that is actually needed for normalized paths. To stay normalized, we don't allow random other ones.
Of course ... I'm quite dispassionate here.
Please see my proposal in
With merged, we still have the expression cleanup the separate issue (enhancement) whether should be allowed, to mean
My remaining points are covered by PRs , , and .
Shouldn't be named according to all other above ?
Yes, I agree. See URL
NAME Are we ready to close this issue now the PRs have been merged or did you have more expression cleanup in mind?
The only thing that comes to my mind is standardizing on the column where the is -- this is currently rather chaotic. But that can be a new issue.
Indentation of : number of lines such indented
(And it doesn't need to be consistent, just a bit less chaotic.)
Let's make the a new issue. (I haven't got a good feel for the optimal solution.)
Before we close this issue, URL slipped through the net in my earlier PRs.
Then could resolve to either or . We would introduce an ambiguity, we already found with Json Pointer () ...
OK, with the latest blank space realignments that are part of (5e2cc85), I think we are done with this.
Thank you! ... or do we need two selectors here (Ch.2.61) child-longhand = "[" S selector 1(S "," S selector) S "]" given that '1' means 'at least one'.

Related discussion:
text: A function argument is a "filter-path" or a "comparable". <del> According to filter-selector, a "function-expression" is valid as a </del> <ins> According to filter-selector, a "function-expr" is valid as a </ins> "filter-path" or a "comparable". Any function expressions in a query must be well-formed (by
Code change:
Thanks to NAME for spotting this.
NAME I presume you are ok with this change, so I'm going to merge it. Any concern, let me know and we can adjust the result.
Yes. Just didn't have chance to check this in context, but if I remember this properly, this change is good (and necessary).

Related discussion:
text: primitive values (that is, numbers, strings, "true", "false", and "null").  These can be obtained via literal values; Singular Queries, each of which selects at most one node the value of which is then <del> used; and function expressions (see fnex) of type "ValueType" or "NodesType" (see type-conv). </del> <ins> used; and function expressions (see fnex) of type "ValueType". </ins> Literals can be notated in the way that is usual for JSON (with the extension that strings can use single-quote delimiters).  Alphabetic
Code change:
Thanks to NAME for spotting this.
NAME I presume you are ok with this change, so I'm going to merge it. Any concern, let me know and we can adjust the result.
Yes. Just didn't have chance to check this in context, but if I remember this properly, this change is good (and necessary).

Related discussion:
text: applies) "NodesType". If it occurs directly as a "comparable" in a comparison, the <del> function is declared to have a result type of "ValueType", or (conversion applies) "NodesType". </del> <ins> function is declared to have a result type of "ValueType". </ins> Otherwise, it occurs as an argument in another function expression, and the following rules for function arguments apply
Code change:
NAME Deleting the text should have addressed your original editorial issue. This PR also adds the missing cross-reference. If you're happy, please approve.

Related discussion:
text: these are used to define "!=", "<=", ">", and ">=". When either side of a comparison results in an empty nodelist or <del> "Nothing": </del> <ins> "Nothing" (see typesys): </ins> a comparison using the operator "==" yields true if and only the other side also results in an empty nodelist or "Nothing".
Code change:
NAME Deleting the text should have addressed your original editorial issue. This PR also adds the missing cross-reference. If you're happy, please approve.

Related discussion:
text: first string compares less than the remainder of the second string. <del> Note that comparisons using the operator "<" yield false if either value being compared is an object, array, boolean, or "null". </del> "!=", "<=", ">", and ">=" are defined in terms of the other comparison operators.  For any "a" and "b":
Code change:
I'll just use a single example here because I think it makes it easier to express my point but the problems might be wider The URI template may include a variable, which is later defined in URL as . The value can only be between 0 through 255, I presume this is a decimal value. What is expected to happen if I send some bad values like: I presume that the recipient would reject the request with a bad path, by virtue of applying the requirement in section 4 that :path SHALL NOT be empty and following the expansion requirements in Section 3 and following those requirements on to Section 4.5. That's a lot of hops to get things right. Is there any easier way to present these?
Agreed, we need better text to specify server handling. For example, we don't currently explicitly that the server has to percent-decode these variables (but we say they have to be percent-encoded). When we add new text about how to extract the variables and decode them, let's also say that the server has to validate that they match requirements and has treat the request as malformed if they don't
NAME can you write up some text?
Appear to look good.

Related discussion:
text: Clients are configured to use IP proxying over HTTP via an URI Template TEMPLATE.  The URI template MAY contain two variables: <del> "target" and "ipproto" (scope).  The optionality of the variables </del> <ins> "target" and "ipproto"; see scope.  The optionality of the variables </ins> needs to be considered when defining the template so that either the variable is self-identifying or it is possible to exclude it in the syntax.
Code change:
I'll just use a single example here because I think it makes it easier to express my point but the problems might be wider The URI template may include a variable, which is later defined in URL as . The value can only be between 0 through 255, I presume this is a decimal value. What is expected to happen if I send some bad values like: I presume that the recipient would reject the request with a bad path, by virtue of applying the requirement in section 4 that :path SHALL NOT be empty and following the expansion requirements in Section 3 and following those requirements on to Section 4.5. That's a lot of hops to get things right. Is there any easier way to present these?
Agreed, we need better text to specify server handling. For example, we don't currently explicitly that the server has to percent-decode these variables (but we say they have to be percent-encoded). When we add new text about how to extract the variables and decode them, let's also say that the server has to validate that they match requirements and has treat the request as malformed if they don't
NAME can you write up some text?
Appear to look good.

Related discussion:
text: tunnel due to a period of inactivity, but they MUST close the request stream when doing so. <ins> A successful response (as defined in Sections resp1 and resp23) indicates that the IP proxy has established an IP tunnel and is willing to proxy IP payloads.  Any response other than a successful response indicates that the request has failed; thus, the client MUST abort the request. </ins> Along with a successful response, the IP proxy can send capsules to assign addresses and advertise routes to the client (capsules).  The client can also assign addresses and advertise routes to the IP proxy for network-to-network routing. <del> By virtue of the definition of the Capsule Protocol (see HTTP-DGRAM), IP proxying requests do not carry any message content.  Similarly, successful IP proxying responses also do not carry any message content. 4.1. </del> <ins> 4.2. </ins> When using HTTP/1.1 H1, an IP proxying request will meet the following requirements:
Code change:
I'll just use a single example here because I think it makes it easier to express my point but the problems might be wider The URI template may include a variable, which is later defined in URL as . The value can only be between 0 through 255, I presume this is a decimal value. What is expected to happen if I send some bad values like: I presume that the recipient would reject the request with a bad path, by virtue of applying the requirement in section 4 that :path SHALL NOT be empty and following the expansion requirements in Section 3 and following those requirements on to Section 4.5. That's a lot of hops to get things right. Is there any easier way to present these?
Agreed, we need better text to specify server handling. For example, we don't currently explicitly that the server has to percent-decode these variables (but we say they have to be percent-encoded). When we add new text about how to extract the variables and decode them, let's also say that the server has to validate that they match requirements and has treat the request as malformed if they don't
NAME can you write up some text?
Appear to look good.

Related discussion:
text: wishes to open an IP forwarding tunnel with no target or protocol limitations, it could send the following request: <del> 4.2. </del> <ins> 4.3. </ins> The IP proxy indicates a successful response by replying with the following requirements:
Code change:
I'll just use a single example here because I think it makes it easier to express my point but the problems might be wider The URI template may include a variable, which is later defined in URL as . The value can only be between 0 through 255, I presume this is a decimal value. What is expected to happen if I send some bad values like: I presume that the recipient would reject the request with a bad path, by virtue of applying the requirement in section 4 that :path SHALL NOT be empty and following the expansion requirements in Section 3 and following those requirements on to Section 4.5. That's a lot of hops to get things right. Is there any easier way to present these?
Agreed, we need better text to specify server handling. For example, we don't currently explicitly that the server has to percent-decode these variables (but we say they have to be percent-encoded). When we add new text about how to extract the variables and decode them, let's also say that the server has to validate that they match requirements and has treat the request as malformed if they don't
NAME can you write up some text?
Appear to look good.

Related discussion:
text: For example, the IP proxy could respond with: <del> 4.3. </del> <ins> 4.4. </ins> When using HTTP/2 H2 or HTTP/3 H3, IP proxying requests use HTTP Extended CONNECT.  This requires that servers send an HTTP Setting as
Code change:
I'll just use a single example here because I think it makes it easier to express my point but the problems might be wider The URI template may include a variable, which is later defined in URL as . The value can only be between 0 through 255, I presume this is a decimal value. What is expected to happen if I send some bad values like: I presume that the recipient would reject the request with a bad path, by virtue of applying the requirement in section 4 that :path SHALL NOT be empty and following the expansion requirements in Section 3 and following those requirements on to Section 4.5. That's a lot of hops to get things right. Is there any easier way to present these?
Agreed, we need better text to specify server handling. For example, we don't currently explicitly that the server has to percent-decode these variables (but we say they have to be percent-encoded). When we add new text about how to extract the variables and decode them, let's also say that the server has to validate that they match requirements and has treat the request as malformed if they don't
NAME can you write up some text?
Appear to look good.

Related discussion:
text: IP packet forwarding, or a specific proxied flow; see scope. An IP proxying request that does not conform to these restrictions is <del> malformed (see H2 and H3). </del> <ins> malformed; see H2 and H3. </ins> For example, if the client is configured with URI Template "https://example.org/.well-known/masque/ip/{target}/{ipproto}/" and wishes to open an IP forwarding tunnel with no target or protocol limitations, it could send the following request: <del> 4.4. </del> <ins> 4.5. </ins> The IP proxy indicates a successful response by replying with the following requirements:
Code change:
I'll just use a single example here because I think it makes it easier to express my point but the problems might be wider The URI template may include a variable, which is later defined in URL as . The value can only be between 0 through 255, I presume this is a decimal value. What is expected to happen if I send some bad values like: I presume that the recipient would reject the request with a bad path, by virtue of applying the requirement in section 4 that :path SHALL NOT be empty and following the expansion requirements in Section 3 and following those requirements on to Section 4.5. That's a lot of hops to get things right. Is there any easier way to present these?
Agreed, we need better text to specify server handling. For example, we don't currently explicitly that the server has to percent-decode these variables (but we say they have to be percent-encoded). When we add new text about how to extract the variables and decode them, let's also say that the server has to validate that they match requirements and has treat the request as malformed if they don't
NAME can you write up some text?
Appear to look good.

Related discussion:
text: For example, the IP proxy could respond with: <del> 4.5. </del> <ins> 4.6. </ins> Unlike UDP proxying requests, which require specifying a target host, IP proxying requests can allow endpoints to send arbitrary IP packets
Code change:
I'll just use a single example here because I think it makes it easier to express my point but the problems might be wider The URI template may include a variable, which is later defined in URL as . The value can only be between 0 through 255, I presume this is a decimal value. What is expected to happen if I send some bad values like: I presume that the recipient would reject the request with a bad path, by virtue of applying the requirement in section 4 that :path SHALL NOT be empty and following the expansion requirements in Section 3 and following those requirements on to Section 4.5. That's a lot of hops to get things right. Is there any easier way to present these?
Agreed, we need better text to specify server handling. For example, we don't currently explicitly that the server has to percent-decode these variables (but we say they have to be percent-encoded). When we add new text about how to extract the variables and decode them, let's also say that the server has to validate that they match requirements and has treat the request as malformed if they don't
NAME can you write up some text?
Appear to look good.

Related discussion:
text: If present, the IP prefix length in "target" SHALL be preceded by a percent-encoded slash ("/"): "%2F".  The IP prefix length MUST <del> represent an integer between 0 and the length of the IP address in bits, inclusive. </del> <ins> represent a decimal integer between 0 and the length of the IP address in bits, inclusive. </ins> <del> "ipproto" MUST represent an integer between 0 and 255 inclusive, or the wildcard value "*". </del> <ins> "ipproto" MUST represent a decimal integer between 0 and 255 inclusive, or the wildcard value "*". </ins> IP proxies MAY perform access control using the scoping information provided by the client: if the client is not authorized to access any of the destinations included in the scope, then the IP proxy can immediately fail the request. <del> 4.6. </del> <ins> 4.7. </ins> This document defines multiple new capsule types that allow endpoints to exchange IP configuration information.  Both endpoints MAY send any number of these new capsules. <del> 4.6.1. </del> <ins> 4.7.1. </ins> The ADDRESS_ASSIGN capsule (see iana-types for the value of the capsule type) allows an endpoint to inform its peer of the list of IP