jiebi/CodeConvo huggingface dataset:
Change:
The document currently assumes that there is one document per repository. That's not always the best structure. It's not uncommon for there to be tight clusters of related documents. QUIC does this (even though it is likely an outlier in the process), but there are also frequent occasions where working groups develop overview documents along with a protocol, or split a document into separate logical pieces (tokbind did this for TLS bits and HTTP bits). URL is something of a train wreck, but there is plenty of middle-ground here.

Discussion:
a minimum) the GitHub account of the user so that their contributions could be tracked more easily. <ins> Some working groups choose to have more than one draft in a repository, particularly for drafts that are tightly linked with significant cross-references.  In such a case, the README for the repository needs to say that clearly so that a participant understands that changes might be made to multiple drafts at once. </ins> 3.2. IETF working group mailing lists are automatically backed up by the
Change:
Here's a chance to actually have the discussion if anyone wants to.
Well, I'm certainly ready for this model.
I'm good with the approach described in the text. As long as a string can be parsed as a Path, it should evaluate. I can't see a case where processing a valid path against a value would produce an error; merely empty result sets. This means that the only errors should be syntax errors, correct?
I think so.
May I encourage reviewers who are in favour of this PR to approve it?
I was awaiting a bit more discussion.
Ok, I've requested a review from Stefan.
Yes absolutely ... I like that clean concept a lot.

Discussion:
JSONPath query, e.g., because of resource depletion, but this is not modeled in the present specification.) <del> Discussion (D1): are we ready for the error model defined here, i.e. one that does not have runtime errors, but only compile time errors? </del> 3.2. In this specification, the semantics of a JSONPath query are defined
Change:
Here's a chance to actually have the discussion if anyone wants to.
One related question is whether the selector can use $ internally (still returning nodes within the current node).
I am in favour of supporting inside filter expressions as a way to access the root node of the argument, but I don't think that should block this PR as the context of the discussion seems to be which nodes are selected. As you point out, using in a filter expression doesn't select the root node - it selects nodes within the current node as usual.
I agree. Paths like should be allowed, but wouldn't select anything that is not a descendent of . Here the provides a basis for comparison used to select the current node in the iteration. I see no value (for an initial release anyway) in allowing selection of ancestor nodes. If a use case and syntax for it are later defined, I'm happy to release that as a follow-up version.
yes ... using in a logical expression is valid and does no harm.
NAME yes, but the issue at hand here is whether there is a mechanism that can select ancestor or cousin nodes. I think we're in agreement that that there is no such mechanism.
Indeed, we seem to be in agreement.

Discussion:
For each node in the list, the selector selects zero or more nodes, each of which is a descendant of the node or the node itself. <del> Discussion (D4): Is that a common requirement?  Or can a selector also go up, or to the query argument? </del> For instance, with the argument "{"a":[{"b":0},{"b":1},{"c":2}]}", the query "$.a[*].b" selects the following list of nodes: "0", "1" (denoted here by their value).  Let's walk through this in detail.
Change:
... and some minor edits ...
Indeed. I'll do a small PR with my points.
a little late to the party ... thanks
[ ] define a production , replacing [ ] go through ABNF and make sure blank space is allowed where it needs to be (Do not use the term "whitespace" any more.) Task "T1" in the document URL
and
From the document: (whitespace is now generally called blank space, but that doesn't change the work to be done.)
and
How much do we want to reference XPath within the spec? I understand that XPath is the inspiration (and in the tagline that NAME used in his blog post: "XPath for JSON"), but I wonder if much of this can be left out of the spec. The argument for this is that we're defining JSONPath. It shouldn't assume any understanding of XPath or any other technology. It's not the job of the specification to convince readers to use it. It's the job of the specification to define the technology. I'm perfectly happy moving this into an external "Understanding JSONPath" website at some point.
I seem to remember that last time we discussed this we agreed to move the introductory comparison with XPath to an appendix, with the possible exception of the overview table (but that could be duplicated).
The XPath inclusion was moved into an appendix.
Do we allow spaces (outside of string literals)? If so, where is whitespace allowed? I think whitespace in query expressions should be allowed. This would fall in to the context of the . Maybe inside the union/ selector: Are there any other places where whitespace could be considered useful?
It may be convenient to allow spaces between matchers - to allow well-readable multi-line queries for complex cases.
Looks like the allows whitespace internally, so that (with leading and trailing whitespace) is valid.
Closed in and
What was the resolution here? Where did we end up allowing whitespace?
This PR could be merged to make progress. Further changes as indicated by NAME are probably needed, either now or in a subsequent PR.

Discussion:
member name ""a"".  The result is again a list of one node: "[{"b":0},{"b":1},{"c":2}]". <del> Next, "[*]" selects from any input node which is an array and selects all the elements of the input node.  The result is a list of three </del> <ins> Next, "[*]" selects from any input node -- either an array or an object -- all its elements or members.  The result is a list of three </ins> nodes: "{"b":0}", "{"b":1}", and "{"c":2}". Finally, ".b" selects from any input node of type object with a
Change:
XPath details are a distraction in the body of the spec. In the future, readers are increasingly likely to come to this spec with no exposure to XPath or, for that matter, XML.
Looks very good, with the one nit. Thanks!

Discussion:
dated 2007-02-21 JSONPath-orig and provides a normative definition for it. <del> inspired-by-xpath provides a brief synopsis with XML's XPath XPath, which was the inspiration that led to the definition of JSONPath. </del> <ins> inspired-by-xpath describes how JSONPath was inspired by XML's XPath XPath. </ins> JSONPath was intended as a light-weight companion to JSON implementations on platforms such as PHP and JavaScript, so instead

The examples in tbl-example use the expression mechanism to obtain the number of elements in an array, to test for the presence of a member in a object, and to perform numeric comparisons of member <del> values with a constant.  For further illustration, the table shows XPath expressions that would be used with a comparable XML document; see also xpath-overview. </del> <ins> values with a constant. </ins> 3.
Change:
There does not seem to be an appetite for doing the necessary spec work. This PR will test that assertion. Filter expressions are still supported, but not "container expressions", of the form [(...)].
I think this can be added later, similar to the consensus for . Personally I still see value in having it.

Discussion:
expressions between the ensuing platform-specific dialects. The present specification intends to remove platform dependencies and <del> server as a common JSONPath specification that can be used across </del> <ins> serve as a common JSONPath specification that can be used across </ins> platforms.  Obviously, this means that backwards compatibility could not always be achieved; a design principle of this specification is to go with a "consensus" between implementations even if it is rough,

start position, an end position, and possibly a step value that moves the position from the start to the end (slice). <del> JSONPath employs an for computing values and making decisions.  The present specification defines a simple expression language that is independent from any scripting language in use on the platform.  JSONPath can use such expression language expressions, written in parentheses: "(<expr>)", as an alternative to explicit names or indices as in [no-dot-length]: The symbol "@" is used for the current node, i.e., the node in the context of which the expression is evaluated. </del> Filter expressions are supported via the syntax "?(<boolean expr>)" as in

4. <del> 5. </del> TBD: Define a media type for JSONPath expressions. <del> 6. </del> <ins> 5. </ins> This section gives security considerations, as required by RFC3552.

isolating a single location within a JSON document.  Path is a query syntax that can also be used to pull multiple locations. <del> [no-dot-length] We probably want to use an expression that does not use </del>
Change:
Thanks, the rebase looks good.
NAME After merging some PRs I fixed a conflict here and then added a commit. PTAL and merge if you are happy.

Discussion:
Regular expression tests can be applied to "string" values only. <ins> Alphabetic characters in ABNF are case-insensitive, so "e" can be either "e" or "E". false, null, true are lower-case only (case-sensitive). </ins> The following table lists filter expression operators in order of precedence from highest (binds most tightly) to lowest (binds least tightly).
Change:
I merged this so once we have published an I-D with this change in it we can initiate the necessary review on the media-types list.
Looks plausible.

Discussion:
4. <del> TBD: Define a media type for JSONPath expressions. </del> <ins> 4.1. IANA is requested to register the following media type RFC6838: Person & email address to contact for further information: iesg@ietf.org </ins> 5.
Change:
Ref: URL
we need to discuss the descendant selector's behavior by including itself to the node list.
Yes. Let's do that in a PR for URL
yes ... it's illustratively shown, what a good thing inline examples are ...
Considering the following input: would evaluate to (in this case the values of the object): I would expect the descendant version: to evaluate to: Yet the example says: Considering the following pseudo logic: In the case of the would be an index wildcard selector. I would expect the descendant selector to (starting by selecting itself) walk through the json structure and select all the results by applying the child selector (dot-member-name, index-selector, index-wild-selector, or wildcard) on each traversed value. Am I misunderstanding something here or is this the intended behavior?
Thanks for raising this. When I was writing the example, I noticed that only a few implementations included the node itself. But the descendant selector semantics currently say: and so I included the "starting" node itself. This is why I included the following text in the commit message: The semantics section needs improving anyway to clarify the semantics of the various forms of the descendants selector. I agree with the semantics proposed above, providing there is a consensus for this in the WG.
In my understanding descendant selector simply extends the single-level operating of child selector , in that it further recursively operates on all other descendant levels. So I agree to Bram's traversal algorithm above. A node is not considered a descendant of itself. Obviously I have not been aware of this behavior.

Discussion:
Note: This ordering of the results for the "$..[*]" and "$..*" examples above is not guaranteed, except that: <del> "{o: {"j": 1, "k": 2}, a: [5, 3]}" must appear before "{"j": 1, "k": 2}" and "[5, 3]", </del> <ins> "{"o": {"j": 1, "k": 2}, "a": [5, 3]}" must appear before "{"j": 1, "k": 2}" and "[5, 3]", </ins> "{"j": 1, "k": 2}" must appear before "1" and "2",

of their element or member values then.  Applied to other value types, it will select nothing. <del> Some examples: </del> <ins> 3.5.8.3. JSON document: Queries: </ins> 3.5.9.

components MUST be in the I-JSON range of exact values, see synsem- overview. <ins> 3.5.9.3. JSON document: Queries: </ins> 3.6. A Normalized Path is a JSONPath with restricted syntax that
Change:
can only produce a singular result since the slice is equivalent to the index . Agreed?
In the first two examples, the Path and Normalized path are equivalent in what they identify. Not so for the third because the Path produces a plural result and thus cannot be normalized. This should probably be noted?

Discussion:
Normalized Paths: "$[-3]", for example, is a Singular Path, but not a Normalized Path. <ins> 3.6.1. </ins> 4. 4.1.
Change:
NAME and NAME Thanks for your help. I verified cut'n'past works correctly.
Some of these are split across lines in awkward places: ! We could either fix the rendering somehow to split at a more acceptable point or change the examples to avoid these awkward splits.
NAME Do you know how to fix the rendering? E.g. I think it would be better not to split the lines in the middle of a quoted string, but splitting after would be ok.
Please check my little tweak to
What if we reduce each aspect to minimal necessary ... ?
This seems to work ...
This is essentially what URL does, except that it uses native nbsps.
ahh ... fine ...
There are two considerations I have in mind: Ease of future editing - may need to add a comment about invisible special characters. Cut'n'paste - need to be able to run the examples and get the same results when clipped from either text or HTML.
Left an editing note. Copy/paste works for me in TXT (which has an ASCII space) and HTML (which has an NBSP, but that gets reduced in copy/paste).
Fixed as part of e82ce1f521e94ee2cd5b93d14726875e94a4a8e7.

Discussion:
3.7.1. <ins> "$["u00b1"]" is normalized into (noise in the table and lack of typewriter font is due to RFCXMLv3 limitations). </ins> 4. 4.1.
Change:
contains a bulleted list of the selector types. Each of the items in the list ends with a period. While it may (or may not) be grammatically correct, it leads to some confusing text, specifically when a selector contains, or completely comprises of, periods. For example: Because we only have plain text, it's really difficult to see what's going on here. Formatted, it would look like which is much clearer. If the spec is to continue being issued in a plain text format, I suggest we remove the ending periods from these lines.

Discussion:
Root selector "$" (used at the start of a query and in expressions) <del> Dot selector ".<name>", used with object member names exclusively. </del> <ins> Dot selector ".<name>", used with object member names exclusively </ins> <del> Dot wildcard selector ".*". </del> <ins> Dot wildcard selector ".*" </ins> Index selector "[<index>]", where "<index>" is either a (possibly negative, see index-semantics) array index or an object member <del> name. </del> <ins> name </ins> <del> Index wildcard selector "[*]". </del> <ins> Index wildcard selector "[*]" </ins> Array slice selector "[<start>:<end>:<step>]", where the optional <del> values "<start>", "<end>", and "<step>" are integer literals. </del> <ins> values "<start>", "<end>", and "<step>" are integer literals </ins> <del> Descendants selector "..". </del> <ins> Descendants selector starting with a double dot ".." </ins> List selector "[<sel1>,<sel2>,...,<selN>]", holding a comma <del> separated list of index and slice selectors. </del> <ins> separated list of index and slice selectors </ins> Filter selector "[?(<expr>)]"
Change:
Fixes URL
In a previous issue, I suggested the idea of adding a processing model description to the specification. So was added. However, in re-reading the current document, I found that the process is repeated (albeit with less detail) in . I think that the language in 3.4 may be sufficient to explain how the path is expected to operate, making the processing model (or at least one of them) somewhat redundant. Can we combine these sections in some way instead of repeating ourselves?
I agree that we could combine these sections and avoid some repetition. I'm inclined to keep the Semantics section and do away with the Processing Model section since I think the term "Processing Model" is a little obscure compared to "Semantics".
Regardless of my question I like the change.

Discussion:
indexing beyond the end of an array, simply result in fewer nodes being selected. <del> Let's walk through an example in detail.  With the argument </del> <ins> Consider this example.  With the argument </ins> "{"a":[{"b":0},{"b":1},{"c":2}]}", the query "$.a[*].b" selects the following list of nodes: "0", "1" (denoted here by their value).
Change:
because it is no longer needed because the expansion is misleading
Why is the expansion misleading?
I would have thought it was because the notation is not just for objects.
Using the expanded version of the acronym gives the impression that this specification is in some way entangled with JavaScript. (The fact that Glyn reads "JavaScript Object" as a reference to the string-keyed maps JavaScript started out with is another example for the confusion.)
I feel like anyone who knows about JSON had likely come across our asked about its relationship with its namesake. I don't really think this is something that is needed. I mean, do it if it makes you feel better, but it's not really necessary.
In the RFC series, the expansion is no longer needed, which is a good thing, because the expansion is misleading. This PR adapts the JSONPath specification to this fact. I'm not sure what "this" and "it" are in your message. This PR is not about making anyone of us feel better, it is about improving the document to be less misleading.
I think we are all agreed that merging is fine.
LGTM, thanks.

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

Discussion:
3.1. A JSONPath query is a string which selects zero or more nodes of a <del> piece of JSON. </del> <ins> JSON value. </ins> A query MUST be encoded using UTF-8.  The grammar for queries given in this document assumes that its UTF-8 form is first decoded into

resource depletion and related errors are comparable to 500 type errors.) <ins> The JSON value the JSONPath query is applied to is, by definition, a valid JSON value.  The parsing of a JSON text into a JSON value and what happens if a JSON text does not represent valid JSON are not defined by this specification. </ins> 3.2. Syntactically, a JSONPath query consists of a root selector ("$"),
Change:
Fix some nits pointed out by NAME Improve definition of children Unicode Scalar Values are integers Typo fix Ordering of non-integer numbers

Discussion:
for each member of the first object with name "n" and value "v", there is a member of the second object with name "n" <del> and value "w" where "v" and "w" yield true when comparsed </del> <ins> and value "w" where "v" and "w" yield true when compared </ins> using "==", and for each member of the second object with name "n" and value "v", there is a member of the first object with name "n" and <del> value "w" where "v" and "w" yield true when comparsed using </del> <ins> value "w" where "v" and "w" yield true when compared using </ins> "==". a comparison using the operator "!=" yields true if and only if

same type which are both numbers or both strings and which satisfy the comparison: <del> numbers in the I-JSON RFC7493 range of exact values MUST compare using the normal mathematical ordering; one or both numbers outside that range MAY compare using an implementation </del> <ins> numbers expected to interoperate as per RFC7493 MUST compare using the normal mathematical ordering; numbers not expected to interoperate as per I-JSON MAY compare using an implementation </ins> specific ordering the empty string compares less than any non-empty string
Change:
There were picked up by NAME Improve table 1 Improve comparison examples Link to Boolean laws Make some examples shorter More list selector examples Compress two examples into one Clarify description of Normalized Paths
NAME The section concerning you needs more work, but I'm going to merge this PR with what we have and start a new one to improve that section.
NAME This should do it: URL

Discussion:
3.4.7.2.4. The logical AND, OR, and NOT operators have the normal semantics of <del> Boolean algebra and consequently obey these laws (where "P", "Q", and "R" are any expressions with syntax "logical-and-expr", "T" is any expression that yields true, such as "1 == 1", and "F" is any expression that yields false, such as "1 == 0"): </del> <ins> Boolean algebra and obey its laws (see, for example, BOOLEAN-LAWS). </ins> 3.4.7.3.

with double quotes) in JSON texts. The syntax of Normalized Paths is restricted so that there is one and <del> only one way of representing any given Normalized Path.  Putting this another way, for any two distinct Normalized Paths, a JSON value exists that will yield distinct results when the Normalized Paths are applied to it. </del> <ins> only one way of identifying a given node.  Putting this another way, two distinct Normalized Paths are never equivalent to each other: there will always be at least one JSON value that yields distinct results when those paths are applied to it. </ins> Certain characters are escaped, in one and only one way; all other characters are unescaped.