jiebi/CodeConvo huggingface dataset:
Change:
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.

Discussion:
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> <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. <del> Every JSONPath query MUST begin with the root identifier "$". </del> <ins> Every JSONPath query (except those inside filter expressions, see filter-selector) MUST begin with the root identifier "$". </ins> 2.4.2.
Change:
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".

Discussion:
Each entry in the registry must include: <del> Initial entries in this sub-registry are as listed in pre-reg: </del> <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.
Change:
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"...

Discussion:
a comparison using the operator "==" yields true if and only if the comparison is between: <del> equal primitive values, </del> <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
Change:
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.

Discussion:
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> <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. <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> <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. <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> <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-
Change:
Fixes URL
is a subtype by coercion of , but Table 13 does not include this subtype relationship.
Not sure I like the concept of "subtype by coercion". One can be used in place of the other as it can be coerced, but that is not usually what we'd call a subtype.
That's a different point really. Table 13 already includes at least one subtype by coercion, so this issue adds another subtype by coercion.
NAME How would you like to proceed with "subtype by coercion"? If we want to explore alternatives, I think it deserves a separate, non-editorial issue.
From the spec, just below : I disagree with the idea that coercion implies subtypes. If I have integer and floating point numeric types, I can cast from one to the other, but that doesn't mean that either is a subtype of the other. C# provides "implicit" casts where the compiler can infer a type cast from context. For example, I think this is closer to what we're dealing with here. We're looking at compatibility and conversion between types, not polymorphism (as "subtype" implies).
If I'm reading the right, it looks like the term is being used to mean different things depending on which column it's in. In column 1 ("Type") or column 3 ("Subtypes"), it's referring to the type system we're creating. In column 2 ("Abstract Instances"), it's referring to the underlying JSON(ish) value kind, i.e. , , , etc, plus . I think having the same word to define these things can be confusing for the reader, and maybe we need something else in one of these places to indicate the distinction. We've already done this for the type to distinguish it from the value.
I'm not sure there is a really good alternative. We could use for abstract instances, but in the rest of the spec, "value" implies a JSON value, so this doesn't seem quite right.
If "value" implies a JSON value (corresponding to the middle column), then we should change the others (the type name). It really is confusing.
In the interim, we decided to append the type names with "Type". I will create a PR for this.
I'm going to wait for to complete before going forward with this as they change the same chunk of text.
Thanks. That's why I am trying to tidy up and get it merged ASAP.
(Modulo the coercion entry on OptionalValue, as discussed.)

Discussion:
A type is a set of instances.  A type is a subtype of another type if its set of instances (possibly after coercion) is a subset of the set <del> of instances of the other type. </del> <ins> of instances of the other type.  The subtype relationship is transitive: for any A, B, and C if B is a subtype of A and C is a subtype of B, then C is a subtype of A. </ins> tbl-types defines the available types in terms of abstract instances, where "n" denotes a node, "v" denotes a value, and "nl" denotes a <del> non-empty nodelist.  The table also lists the subtypes of each type. </del> <ins> non-empty nodelist.  The table also lists the (immediate) subtypes of each type. </ins> Notes:
Change:
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

Discussion:
"[{"j": 4}, {"k": 6}]" must appear before "{"j": 4}" and "{"k": 6}", <del> "{"j": 4}" must appear before "4", and </del> <ins> "{"j": 4}" must appear before "{"k": 6}", </ins> <del> "{"k": 6}" must appear before "6". </del> <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
Change:
Fix a right margin incursion, as well.
I'm commenting on the editor's draft. Section 2.6 says, of len(), count(), match(), and search(), that “they are an integral part of the JSONPath specification and are mandatory to implement.” My intuition is that this is not consistent with the WG charter. I think we're supposed to be specifying the GCD of JSONPath implementations, not enriching the language. The actual words of the charter are “based on the common semantics and other aspects of existing implementations”. Do len(), count(), match(), and search() qualify?
Most implications support regexps in filters, so we need to support those somehow. A function extension seems like the neatest solution.
Most implementations also support length in some way, usually , which we've decided against.
Guilty as charged. In that sentence I tried to express that, although the four functions make use of an extension point, they are not extensions of the base standard, as are none of the other features defined in the document. We don't define compliance, but we do fan the expectation that a JSONPath implementation will not leave out a feature that seems inconvenient to implement (say, descendants segments). If you have better wording, we could take that.
In all implementations there is some degree or level of compliance with the specification. No matter what the wording is in the specification the implementations will stand as they are and users will evaluate them based on how well or how compliant it is with the spec but more importantly how useful they are to them. In my implementation for go I have not yet implemented functions but do support regex with a . As this specification solidifies I'll also support the changes but in the interest of not breaking existing code that uses the OjG package I'll keep the original implementation as well.
NAME that's expected from most implementers, including myself. However, also as one of the editors, I would hope that implementors default to spec compliant behavior, offering other functionality behind options that the user must explicitly set. This is fairly common for spec implementations and what I will be doing if I decide to support extra-spec functionality.
I may not put it as eloquently as you do but I agree 100%. I hope I can contribute at some point.

Discussion:
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 <del> JSONPath specification and are mandatory to implement. </del> <ins> JSONPath specification and are expected to be implemented like any other integral part of this specification. </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
Change:
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.

Discussion:
"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> <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 <del> "NodesType" have no syntactical representation in JSONPath. </del> <ins> "NodesType" have no direct syntactical representation in JSONPath. </ins> The abstract instances above can be obtained from the concrete representations in tbl-typerep.
Change:
Wouldn't mind if we could get these editorials merged quickly so the bulk of the other PRs shrinks a bit.
LGTM, thanks.

Discussion:
Note: "double-quoted" strings follow the JSON string syntax (RFC8259); "single-quoted" strings follow an analogous pattern <del> (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). </del> <ins> (syntax-index).  No attempt was made to improve on this syntax, so if it is desired to escape 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), they need to be represented by a pair of surrogate escapes (""uD83EuDD14"" in this case). </ins> 2.5.1.2. <del> A "name-selector" string MUST be converted to a member name M by </del> <ins> A "name-selector" string MUST be converted to a member name "M" by </ins> removing the surrounding quotes and replacing each escape sequence with its equivalent Unicode character, as in the table below: Applying the "name-selector" to an object node selects a member value <del> whose name equals the member name M, or selects nothing if there is </del> <ins> whose name equals the member name "M", or selects nothing if there is </ins> no such member value.  Nothing is selected from a value that is not an object. Note that processing the name selector requires comparing the member <del> name string M with member name strings in the JSON to which the </del> <ins> name string "M" with member name strings in the JSON to which the </ins> selector is being applied.  Two strings MUST be considered equal if and only if they are identical sequences of Unicode scalar values. In other words, normalization operations MUST NOT be applied to <del> either the member name string M from the JSONPath or to the member </del> <ins> either the member name string "M" from the JSONPath or to the member </ins> name strings in the JSON prior to comparison. 2.5.1.3.
Change:
These editorial changes from PR are needed in the base.
I confess I tend to write tedious text when precision is at stake. Hopefully, the second commit avoids the tedium.
Why was this merged so quickly?!
We merged this editorial change quickly so we could rebase the other substantive PRs on it and put us in a better position to compare their pro's and con's.
Looks good now! Should merge this quickly so we can rebase the others.

Discussion:
they work with paths that select structured values. <del> To test the value of a node selected by a path, an explicit </del> <ins> To examine the value of a node selected by a path, an explicit </ins> comparison is necessary.  For example, to test whether the node selected by the path "@.foo" has the value "null", use "@.foo == null" (see null-semantics) rather than the negated existence test

The comparison operators "==" and "<" are defined first and then these are used to define "!=", "<=", ">", and ">=". <del> When a path resulting in an empty nodelist appears on either side of a comparison: </del> <ins> When either side of a comparison results in an empty nodelist or "Nothing": </ins> <del> a comparison using the operator "==" yields true if and only if the comparison is between two paths each of which result in an empty nodelist. </del> <ins> a comparison using the operator "==" yields true if and only the other side also results in an empty nodelist or "Nothing". </ins> a comparison using the operator "<" yields false. <del> When any path on either side of a comparison results in a nodelist consisting of a single node, each such path is replaced by the value of its node and then: </del> <ins> When any path or function expression on either side of a comparison results in a nodelist consisting of a single node, that side is replaced by the value of its node and then: </ins> a comparison using the operator "==" yields true if and only if the comparison is between:

2.6.1. <del> Each parameter and the result of a function extension must have a declared type. </del> <ins> Each parameter as well as the result of a function extension must have a declared type. </ins> A type is a set of instances.  Declared types enable checking a JSONPath query for well-typedness independent of any argument the

function is declared to have a result type of "ValueType", or (conversion applies) "NodesType". <del> Otherwise, it is occurring as an argument to a further function </del> <ins> Otherwise, it occurs as an argument in another function </ins> expression, and the following rules for function arguments apply to its declared result type.
Change:
PR changed the spec to use "path" only for paths, and "query" for queries. The term "JSONPath" is then left in need of some motivation. This is provided in the History section so as not to interfere with the normative text.
... fine ...

Discussion:
even if it is rough, as long as that does not jeopardize the objective of obtaining a usable, stable JSON query language. <ins> The term was chosen because of the XPath inspiration and also because the outcome of a query consists of identifying nodes in the JSON argument. </ins> 1.3. The JSON value a JSONPath query is applied to is, by definition, a
Change:
The draft currently mentions an "IP forwarding path" (or elsewhere a "path for proxying IP packets") without defining what that term means. It's ambiguous because "path" is a . I'd propose we replace this use of the word "path" with the word "tunnel" which is .
Yes, "IP forwarding tunnel" sounds fine to me.
Yes tunnel is good. Or maybe association in the context of handling state st the proxy.

Discussion:
The Extended CONNECT protocol defined for this mechanism is "connect- ip", which is also referred to as CONNECT-IP in this document. <del> The CONNECT-IP protocol allows endpoints to set up a path for </del> <ins> The CONNECT-IP protocol allows endpoints to set up a tunnel for </ins> proxying IP packets using an HTTP proxy.  This can be used for various solutions that include general-purpose packet tunnelling, such as for a point-to-point or point-to-network VPN, or for limited

IP packets in HTTP Datagrams (packet-handling). Any 2xx (Successful) response indicates that the proxy is willing to <del> open an IP forwarding path between it and the client.  Any response </del> <ins> open an IP forwarding tunnel between it and the client.  Any response </ins> other than a successful response indicates that the tunnel has not been formed.

request.  A client MUST treat a successful response containing any Content-Length or Transfer-Encoding header fields as malformed. <del> The lifetime of the forwarding path is tied to the CONNECT stream. </del> <ins> The lifetime of the forwarding tunnel is tied to the CONNECT stream. </ins> Closing the stream (in HTTP/3 via the FIN bit on a QUIC STREAM frame, <del> or a QUIC RESET_STREAM frame) closes the associated forwarding path. </del> <ins> or a QUIC RESET_STREAM frame) closes the associated forwarding tunnel. </ins> Along with a successful response, the proxy can send capsules to assign addresses and routes to the client (capsules).  The client can

In the other direction, when a CONNECT-IP endpoint receives an IP packet, it checks to see if the packet matches the routes mapped for <del> a CONNECT-IP forwarding path, and performs the same forwarding checks as above before transmitting the packet over HTTP Datagrams. </del> <ins> a CONNECT-IP forwarding tunnel, and performs the same forwarding checks as above before transmitting the packet over HTTP Datagrams. </ins> Note that CONNECT-IP endpoints will decrement the IP Hop Count (or TTL) upon encapsulation but not decapsulation.  In other words, the

server through the proxy. The following example shows an IP flow forwarding setup, where a <del> client requests to establish a forwarding path to target.example.com using ICMP (IP protocol 1), and receives a single local address and remote address it can use for transmitting packets. </del> <ins> client requests to establish a forwarding tunnel to target.example.com using ICMP (IP protocol 1), and receives a single local address and remote address it can use for transmitting packets. </ins> The following example shows a proxied UDP listen flow, where a client receives can receive UDP packets via the proxy, and can send to any
Change:
Where the word "lesser" is used, I think "less than" would read better. Especially in the construct "lesser or equal than"
SGTM

Discussion:
Range A precedes an IP address range B in the same ROUTE_ADVERTISEMENT capsule, they MUST follow these requirements: <del> IP Version of A MUST be lesser or equal than IP Version of B </del> <ins> IP Version of A MUST be less than or equal than IP Version of B </ins> If the IP Version of A and B are equal, the IP Protocol of A MUST <del> be lesser or equal than IP Protocol of B. </del> <ins> be less than or equal than IP Protocol of B. </ins> If the IP Version and IP Protocol of A and B are both equal, the End IP Address of A MUST be strictly less than the Start IP