jiebi/CodeConvo huggingface dataset:
Change:
The one to one correspondence sentence gives us most of the desired properties. The fact that for distinct Normalized Paths there will always be at least one JSON value which can distinguish the paths is interesting but not crucial. If it's confusing to some people, then it's probably a distraction.
yes ... this is a good minimalistic solution ... thanks

Discussion:
escaping when Normalized Paths appear as strings (which are delimited with double quotes) in JSON texts. <del> The syntax of Normalized Paths is restricted so that there is one and 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. </del> Certain characters are escaped, in one and only one way; all other characters are unescaped.
Change:
The deleted text referred, erroneously, to an example obtaining the number of elements in an array. It also used the term "expression mechanism" instead of "filter expression". On the whole, it seemed better to slim the text down to the bare minimum.

Discussion:
The examples are based on the simple JSON value shown in fig-example- value, representing a bookstore (that also has bicycles). <del> 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 an object, and to perform numeric comparisons of member values with a constant. </del> <ins> tbl-example shows some JSONPath queries that might be applied to this example and their intended results. </ins> 3.
Change:
This is a stab at addressing one NAME review comments in PR .
NAME If you don't think this PR is going in the right direction, please close it and we'll circle back to the matter later.
The term "current node" is traditionally used with iterating over children of structured nodes in filter selectors. Now it also appears in 3.3 Semantics chapter in a different context: To avoid confusion of readers, we might use a different term there. A good alternative would be "context node", which is also used by XPath in a similar context.
Perhaps a simple solution would be to avoid the use of the term in 3.3 as this term doesn't appear to be used elsewhere.
Please see the simplification in URL

Discussion:
JSONPath expressions are applied to a JSON value, the <del> .  Within the JSONPath expression, the abstract name "$" is used to refer to the </del> <ins> . A JSONPath expression consists of an identifier followed by a series of zero or more segments each of which contains one or more selectors. 1.3.1. The "$" refers to the of the argument, i.e., to the argument as a whole.  Every JSONPath expression begins with the root node identifier. The "@" refers to the </ins> <del> of the argument, i.e., to the argument as a whole. </del> <ins> in the context of the evaluation of a filter expression (described later). </ins> <del> JSONPath expressions use the </del> <ins> 1.3.2. Segments can use the </ins> , for example:

, for example: <del> to build paths that are input to a JSONPath implementation.  A single path may use a combination of bracket and dot notations. </del> <ins> A JSONPath expression may use a combination of bracket and dot notations. </ins> Dot notation is a shorthand way of writing certain bracket notations. <ins> This document treats the bracket notations as canonical and defines various shorthands in terms of bracket notation.  Examples and descriptions use shorthands where convenient. 1.3.3. </ins> A wildcard "*" (wildcard) in the expression "[*]" selects all children of an object or an array and in the expression "..[*]" selects all descendants of an object or an array.

Filter expressions "?<boolean expr>" select certain children of an object or array as in <ins> 1.3.4. </ins> tbl-overview provides a quick overview of the JSONPath syntax elements. <del> This document treats the bracket notations as canonical and defines the above shorthands in terms of the canonical bracket notation. </del> 2. This section provides examples of JSONPath expressions.  The examples
Change:
Fixes URL
Do we intend to replace this with anything? What is its purpose in being here?
The N-1 line also illustrates the point so I think it's probably OK to leave it?
Sorry, I didn't pay attention. The purpose of this example was to show that escaped characters are normalized into their actual equivalents (unless there is a reason not to do so). The messiness is a workaround for xml2rfc bugs. I'm confident we can get these bugs fixed before this is published; otherwise we might indeed want to skip this example.
Why doesn't the example already show that an escaped character is normalised into its actual equivalent ("a")?
It does. Many implementers will however think that this only applies to 95-ASCII characters (there is no reason for thinking that, but it is a highly likely misunderstanding).
The last entry in table 15 is completely incomprehensible and the explanation in the following paragraph doesn't help. Not sure how to work around this within the limitations of xml2rfc but maybe just leave it out, it's implicit in the 2nd-last-line example.
NAME I presume you are referring to with the caption "Normalized Path examples". (Table 15 at is a different one.) I agree the example is a mess and doesn't pull its weight, so I'll submit a PR to delete it.
I think it is useful to have an example that shows characters are not normally escaped, even if they are beyond ASCII.
(By the time this goes by the RFC editor, we may be able to get rid of the useless U+.... stuff added by xml2rfc.)

Discussion:
3.8.1. <del> "$["u00b1"]" is normalized into (noise in the table and lack of typewriter font is due to RFCXMLv3 limitations). </del> 4. 4.1.
Change:
This is an attempt to make two sentences in the abstract and introduction less clunky while not jettisoning their precision.
Thanks NAME I see you managed to approve a draft PR - interesting.
Works for me, although one would need to understand that JSON values are nested to understand the abstract. (But we can't start from the creation of the universe.)

Discussion:
Abstract <del> JSONPath defines a string syntax for selecting and extracting values within a JSON (RFC 8259) value. </del> <ins> JSONPath defines a string syntax for selecting and extracting JSON (RFC 8259) values from a JSON value. </ins> 1. JSON RFC8259 is a popular representation format for structured data <del> values.  JSONPath defines a string syntax for identifying values within a JSON value. </del> <ins> values.  JSONPath defines a string syntax for selecting and extracting JSON values from 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
I left that in deliberately. We have removed the colliding term and we are now free to use current node () throughout. I will follow up with a PR which does just that. I objected to the term "function" in this context previously. I'll follow up with a PR to delete it, which will leave it free for function extensions.
The term "current node" is traditionally used with iterating over children of structured nodes in filter selectors. Now it also appears in 3.3 Semantics chapter in a different context: To avoid confusion of readers, we might use a different term there. A good alternative would be "context node", which is also used by XPath in a similar context.
Perhaps a simple solution would be to avoid the use of the term in 3.3 as this term doesn't appear to be used elsewhere.
Please see the simplification in URL
Note that there is still an instance of "current node identifier" in table 1. I also note that then English usage of "function" now collides with the term we coin in the function extensions. But the basic change here is right, so I approve.

Discussion:
empty nodelist is a valid query result. A segment performs its function on each of the nodes in its input <del> nodelist.  During such a function execution, each such node is referred to as the "current node".  Each of these function executions produces a nodelist, which are then concatenated to produce the result of the segment.  A node may be selected more than once and appears that number of times in the nodelist.  Duplicate nodes are not removed. </del> <ins> nodelist.  Each of these function executions produces a nodelist, which are then concatenated to produce the result of the segment.  A node may be selected more than once and appears that number of times in the nodelist.  Duplicate nodes are not removed. </ins> A syntactically valid segment MUST NOT produce errors when executing the query.  This means that some operations that might be considered
Change:
There may be some more shake-out as filter semantics are scattered through the syntax section. We may need to live with this because it makes more sense to talk about semantics in the context of each particular piece of syntax. But let's use the current PR just to use the current node term consistently.

Discussion:
3.5.5.1. <del> The filter selector has the form "?<expr>".  It works via iterating over structured values, i.e. arrays and objects. </del> <ins> The filter selector has the form "?<expr>".  It iterates over structured values, i.e., arrays and objects. </ins> <del> During the iteration process each array element or object member is visited and its value -- accessible via symbol "@" -- or one of its descendants -- uniquely defined by a relative path -- is tested against a boolean expression "boolean-expr". The current item is selected if and only if the boolean expression yields true. </del> <ins> During the iteration process the node of each array element or object member being visited is known as the current node.  A boolean expression, usually involving the current node, is evaluated and the current node is selected if and only if the expression yields true. </ins> Paths in filter expressions are Singular Paths, each of which selects at most one node. <ins> The current node is accessible via the current node identifier "@". </ins> Parentheses MAY be used within "boolean-expr" for grouping. Comparisons are restricted to Singular Path values and primitive

nodelist is not stipulated, since JSON objects are unordered. Children of an array appear in array order in the resultant nodelist. <del> A relative path, beginning with "@", refers to the current array element or member value as the filter selector iterates over the array or object. </del> 3.5.5.2.1. A singular path by itself in a Boolean context is an existence test
Change:
Non-normative may be a better option, throughout, because surely normative sections are informative too? NAME WDYT?
Given we use Informative for the non-normative references, I guess we should do the same throughout. Hopefully no-one will misunderstand...

Discussion:
3.5.4.2.1. <del> This section is non-normative. </del> <ins> This section is informative. </ins> Array slicing is inspired by the behavior of the "Array.prototype.slice" method of the JavaScript language as defined
Change:
This is currently done inconsistently and doesn't add much value. Instead, define terms in the Terminology section. Reviewers please note: is not modified. This avoids a clash with URL which deletes the term.
Let's wait until lands before sorting this PR out. Meanwhile, rebased on main and kept one of the italicisations which was previously removed.
I've reinstated the other italics which NAME favoured.

Discussion:
This section is informative. <del> A JSONPath expression is applied to a JSON value, the .  The output is a nodelist. </del> <ins> A JSONPath expression is applied to a JSON value, known as the argument.  The output is a nodelist. </ins> A JSONPath expression consists of an identifier followed by a series of zero or more segments each of which contains one or more

1.4.1. <del> The "$" refers to the of the argument, i.e., to the argument as a whole.  Every JSONPath expression begins with the root node identifier. </del> <ins> The root node identifier "$" refers to the root node of the argument, i.e., to the argument as a whole.  Every JSONPath expression begins with the root node identifier. </ins> <del> The "@" refers to the in the context of the evaluation of a filter expression (described later). </del> <ins> The current node identifier "@" refers to the current node in the context of the evaluation of a filter expression (described later). </ins> 1.4.2.

value). The query is a root identifier followed by a sequence of zero or more <del> , each of which is applied to the result of the previous root </del> <ins> segments, each of which is applied to the result of the previous root </ins> identifier or segment and provides input to the next segment.  These results and inputs take the form of a nodelist.
Change:
Now we have switched to using function extensions for regexp filter matches, the current syntax requires the result to be compared against a boolean, as shown in this example from PR 330: This is consistent with the following statement in the "Existence Tests" section of the spec: If we wanted the following syntax to act as a regexp test: we would have to allow a function expression (returning a boolean result) to be treated as a (rather than an or a ). This would require (a) considerable rework of filter selectors and (b) making a special case of functions which return booleans. To be clear: I am not in favour of such a change. The reason for raising this issue was so that it doesn't come as a surprise to the WG. Thanks to NAME who spotted it when reviewing some draft input to PR 330.
This was fixed by the above PR.
Excellent!

Discussion:
"Value" is an abstraction of a primitive value. <ins> "Boolean" is an abstraction of a primitive value that is either "true" or "false". </ins> "OptionalValue" is an abstraction of a primitive value that may also be absent.

If it occurs as a "filter-path" in an existence test, the function is defined to have result type "OptionalNodes" or one of its <ins> subtypes, or to have result type "OptionalBoolean" or one of its </ins> subtypes. If it occurs as a "comparable" in a comparison, the function is
Change:
Signed-off-by: Tim Bray Nothing fancy here, just like the title says.
LGTM, thanks.

Discussion:
This document models the result of applying a query to the argument as a nodelist (a list of nodes). <del> So nodes are the selectable parts of the argument.  The only parts of an object that can be selected by a query are the member values. Member names and members (name/value pairs) cannot be selected.  So </del> <ins> Nodes are the selectable parts of the argument.  The only parts of an object that can be selected by a query are the member values.  Member names and members (name/value pairs) cannot be selected.  Thus, </ins> member values have nodes, but members and member names do not. Similarly, member values are children of an object, but members and member names are not.

2.1. <del> A JSONPath expression is a string which, when applied to a JSON value, the </del> <ins> A JSONPath is a string which, when applied to a JSON value, the </ins> , selects zero or more nodes of the argument and outputs these nodes as a nodelist.

In this document, the semantics of a JSONPath query define the required results and do not prescribe the internal workings of an <del> implementation. </del> <ins> implementation.  This document may describe semantics in a procedural step-by-step fashion, but such descriptions are normative only in the sense that any implementation MUST produce an identical result, but not in the sense that implementors are required to use the same algorithms. </ins> The semantics are that a valid query is executed against a value, the

A "dot-member-name-shorthand" of the form ".<member-name>" is shorthand for "['<member-name>']", but can only be used with member names that are composed of certain characters.  Thus, for example, <del> "$.foo.bar" is shorthand for "$['foo']['bar']" (and not for </del> <ins> "$.foo.bar" is shorthand for "$['foo']['bar']" (but not for </ins> "$['foo.bar']"). 2.7.1.2.
Change:
Add note that using the extension point mechanism doesn't imply the "function extensions" to be non-mandatory.

Discussion:
subsections, JSONPath defines an extension point that can be used to add filter expression functionality: "Function Extensions". <ins> This section defines the extension point as well as four function extensions that use this extension point.  While these mechanisms are designed to use the extension point, they are an integral part of the JSONPath specification and are mandatory to implement. </ins> A function extension defines a registered name (see iana-fnex) that can be applied to a sequence of zero or more arguments, producing a result.
Change:
Remove single-valued type "Absent". This is not useful as a function signature type (parameter or result).
I'm looking at 2.6.1 and wondering if it would be meaningful for a function to have a result type of . How could such a function be used in a filter? If it is the case that this doesn't make sense, that should probably be noted in the text.
By "absent" do you mean "no return value," like a function in C? If so, what would be the point? The usefulness of functions is that they perform calculations on inputs and provide a result.
Indeed, the clarification should be that not all types that make up the type hierarchy are useful as return types. (Which does not mean they need to be outlawed -- they are just not useful.)
No. is a type with one instance ().
I can just about conceive of a logging function that doesn't need to return a value returning type . It could be used in a filter expression like this . I'm not suggesting that's a good idea, but it could be done.
That has no impact on the output of the query, though. Why would one include such a thing? Logging is an implementation/application concern. What? I'm asking about the meaning of . How is it used? What's it's purpose? It doesn't appear in the spec anywhere, so why even ask the question?
2023-01-10 Interim: Remove Absent type.

Discussion:
"true" or "false". "OptionalValue" is an abstraction of a primitive value that may <del> also be absent. "Absent" is an abstraction of an empty nodelist. </del> <ins> alternatively be absent ("Nothing"). </ins> "OptionalNodes" is an abstraction of a "filter-path" (which appears in an existence test or as a function argument).
Change:
clarify that filter expressions are side-effect free and therefore, short-circuiting does not make a difference
In C# (and probably other C-style languages), there are two variants for these operators. and are simple boolean logic. They evaluate all of their operands always (left to right). and are "short-circuit" logic. Their operands are evaluated left to right, and as soon as an outcome is known, it stops evaluating. For example, in , the is never evaluated because returns false so the evaluator knows the entire expression will be false. This becomes important for C# as the operands may be methods which have side effects. If I am trying to parse a , then use the I parsed, I can do that all in one statement: (assume returns a ) In this case, never gets called, which means that no log entry is made. But if I use instead will always be called and a log entry will always be created. ( will be the default (0), but it will still be called.) I'm not sure whether we care about such side effects in JSON Path (I'm leaning towards probably not), but it seems necessary to raise the issue. I expect that if we don't care about side effects, this comes down to an optimization strategy and implementor's choice.
This may become more important if certain function extensions end up having side effects. Perhaps we should say implementations MAY short circuit evaluation. Then it's up to users and function extensions to cope.
Actually, it would already become important as soon as we have exception-like semantics on subexpressions. I'd prefer not to have them.
2023-01-10 Interim: Add text that explicitly excludes side effects that affect the evaluation of JSONpath (e.g., beyond memoization or logging), but makes clear that short-circuiting is a valid implementation strategy; functions need to be pure functions.

Discussion:
expression, usually involving the current node, is evaluated and the current node is selected if and only if the expression yields true. <ins> As the expression is composed of side-effect free components, the order of evaluation does not need to be (and is not) defined. Similarly, for "&&"/"||", both a short-circuiting and a fully evaluating implementation will lead to the same result; both implementation strategies are therefore valid. </ins> The current node is accessible via the current node identifier "@". This identifier addresses the current node of the filter-selector that is directly enclosing the identifier; note that within nested

can be applied to a sequence of zero or more arguments, producing a result. <ins> A function extension MUST be defined such that its evaluation is side-effect free, i.e., all possible orders of evaluation and choices of short-circuiting or full evaluation of an expression containing it must lead to the same result.  (Note that memoization or logging are not side effects in this sense as they are visible at the implementation level only -- they do not influence the result of the evaluation.) </ins> A function argument is a "filter-path" or a "comparable". According to filter-selector, a "function-expression" is valid as a
Change:
Delete the editor's note as »Note that there is no deduplication of the nodelist.« is now the agreed behavior.
As currently specified, there is no deduplication of nodes input to the count() function extension. But the spec contains a placeholder suggesting discussion of deduplication. This issue is for that discussion. This issue is related to URL because if function extensions do not have access to node location, then it would not be possible to deduplicate on node identity, only potentially on value.
2023-01-10 Interim: Remove the editor's note now.

Discussion:
Its only argument is a nodelist.  The result is a value, an unsigned integer, that gives the number of nodes in the nodelist.  Note that <del> there is no deduplication of the nodelist. [dedup] </del> <ins> there is no deduplication of the nodelist. </ins> 2.6.5.

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

Discussion:
If the argument value is an object, the result is the number of members in the object. <del> For any other argument value, the result is one. </del> <ins> For any other argument value, the result is "Nothing". </ins> 2.6.4.