jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-jsonpath-base

Commentary: Also add some general advice from See also . Ref : 
 Recursion is not really the problem , stack depth is ( or any other uncontrolled resource usage triggered by queries into deeply nested structures ) .  ,    you comfortable with this now , or would you perhaps like to suggest some other way to address the concerns of 
 Thank you . Looks good and informative to me .
Paragraph (version A):
Attacks on availability may attempt to trigger unusually expensive
runtime performance exhibited by certain implementations in certain
cases.  (See RFC8949 for issues in hash-table implementations, and I-
D.draft-bormann-jsonpath-iregexp for performance issues in regular
expression implementations.)  Implementers need to be aware that good
average performance is not sufficient as long as an attacker can
choose to submit specially crafted JSONPath queries that trigger
surprisingly high, possibly exponential, CPU usage.
Paragraph (version B):
Attacks on availability may attempt to trigger unusually expensive
runtime performance exhibited by certain implementations in certain
cases.  (See RFC8949 for issues in hash-table implementations, and I-
D.draft-bormann-jsonpath-iregexp for performance issues in regular
expression implementations.)  Implementers need to be aware that good
average performance is not sufficient as long as an attacker can
choose to submit specially crafted JSONPath queries or arguments that
trigger surprisingly high, possibly exponential, CPU usage or, for
example via a naive recursive implementation of the descendant
selector, stack overflow.  Implementations need to have appropriate
resource management to mitigate these attacks.
Draft: draft-ietf-jsonpath-base

Commentary: Per discussion at recent interim . 
 Oops yes thanks done .
Paragraph (version B):
Note that processing the dot selector, string-valued index selector,
and filter selector all potentially require matching strings against
strings, with those strings coming from the JSONPath and from member
names and string values in the JSON to which it is being applied.
Two strings MUST be considered equal if and only if they are
identical sequences of Unicode code points.  In other words,
normalization operations MUST NOT be applied to either the string
from the JSONPath or from the JSON prior to comparison.
Draft: draft-ietf-jsonpath-base

Commentary: Ref : 
 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 
 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  's traversal algorithm above . A node is not considered a descendant of itself . Obviously I have not been aware of this behavior .
Paragraph (version A):
"{o: {"j": 1, "k": 2}, a: [5, 3]}" must appear before "{"j": 1,
"k": 2}" and "[5, 3]",
Paragraph (version B):
"{"o": {"j": 1, "k": 2}, "a": [5, 3]}" must appear before "{"j":
1, "k": 2}" and "[5, 3]",
Draft: draft-ietf-jsonpath-base

Commentary: Editorial change only - merged . 
 LGTM
Paragraph (version A):
A selector may select zero or more nodes for further processing.  A
syntactically valid selector MUST NOT produce errors.  This means
that some operations which might be considered erroneous, such as
indexing beyond the end of an array, simply result in fewer nodes
being selected.
Paragraph (version B):
A selector may select zero or more nodes for further processing.  A
syntactically valid selector MUST NOT produce errors.  This means
that some operations that might be considered erroneous, such as
indexing beyond the end of an array, simply result in fewer nodes
being selected.
Paragraph (version A):
The "index-selector" applied with a "quoted-member-name" to an object
selects the node of the corresponding member value from it, if and
only if that object has a member with that name.  Nothing is selected
from a value which is not a object.
Paragraph (version B):
The "index-selector" applied with a "quoted-member-name" to an object
selects the node of the corresponding member value from it, if and
only if that object has a member with that name.  Nothing is selected
from a value that is not a object.
Paragraph (version A):
A slice expression selects a subset of the elements of the input
array, in the same order as the array or the reverse order, depending
on the sign of the "step" parameter.  It selects no nodes from a node
which is not an array.
Paragraph (version B):
A slice expression selects a subset of the elements of the input
array, in the same order as the array or the reverse order, depending
on the sign of the "step" parameter.  It selects no nodes from a node
that is not an array.
Paragraph (version A):
The syntax of Normalized Paths is restricted so that there is one and
only one way of representing any given Normalized Path.  Putting this
another way, for any two distinct Normalized Paths, a JSON document
exists which will yield distinct results when the Normalized Paths
are applied to it.
Paragraph (version B):
The syntax of Normalized Paths is restricted so that there is one and
only one way of representing any given Normalized Path.  Putting this
another way, for any two distinct Normalized Paths, a JSON document
exists that will yield distinct results when the Normalized Paths are
applied to it.
Draft: draft-ietf-jsonpath-base

Commentary: 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 .
Paragraph (version A):
TBD: Define a media type for JSONPath expressions.
Draft: draft-ietf-jsonpath-base

Commentary: Thanks , the rebase looks good . 
 After merging some PRs I fixed a conflict here and then a commit . PTAL and merge if you are happy .
Paragraph (version B):
Alphabetic characters in ABNF are case-insensitive, so "e" can be
either "e" or "E".
Paragraph (version B):
false, null, true are lower-case only (case-sensitive).
Draft: draft-ietf-jsonpath-base

Commentary: It would be good to address comments in this PR . I have made some suggestions , but feel free to pick them apart if you are keen to retain " truthiness " and " falsiness " . BTW perhjaps I struggle with the latter term because of the existence of some . 
 Indeed . It is not that easy to say here what needs to be said , so I 'm still in thinking mode . Thanks for the pointer to English slang ; of course I was completely unaware . We do n't want to use the fooiness terms . Interestingly , the remaining grammar does not seem to have a place where  values are implicitly converted to Boolean ; this is now all explicit unless I 'm missing something . So maybe we do n't need this table ( and its legend ) at all ? 
 You 're right ! The two occurrences of are as follows . which simply tests for non - existence of a value(s ) selected by a path and does not depend on the actual values themselves . which negates a boolean expression . Looking at the details of , there 's no way it can result in a value which might need to be converted to boolean . So please can we scrap the table and kiss " fooiness " goodbye once and for all ? 
 I think we should first merge it and then delete it , in case we need to resurrect it later . 
 what 's about ... which can surely be converted to a negated form . But sometimes someone does n't want to do that ... like in any programming language . Nevertheless I second to kick fooiness out . As a minimalist I am always a friend of kicking unneeded things out . 
 Comparisons already yield Boolean values , as does /. 
 Well , then in fact I misunderstood  's comment above ... I agree to remove the conversion table as superfluous .
Paragraph (version A):
Note that the "dot-selector" follows the philosophy of JSON strings
and is allowed to contain bit sequences that cannot encode Unicode
characters (a single unpaired UTF-16 surrogate, for example).  The
behaviour of an implementation is undefined for member names which do
not encode Unicode characters.
Draft: draft-ietf-jsonpath-base

Commentary: 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 later , similar to the consensus for . Personally I still see value in having it .
Paragraph (version A):
The present specification intends to remove platform dependencies and
server as a common JSONPath specification that can be used across
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,
as long as that does not jeopardize the objective of obtaining a
usable, stable JSON query language.
Paragraph (version B):
The present specification intends to remove platform dependencies and
serve as a common JSONPath specification that can be used across
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,
as long as that does not jeopardize the objective of obtaining a
usable, stable JSON query language.
Paragraph (version A):
The symbol "@" is used for the current node, i.e., the node in the
context of which the expression is evaluated.
Draft: draft-ietf-jsonpath-base

Commentary: From the meeting at IETF 112 ( [ 1 ] ): Consensus : ' in ' wo n't be used , but it will be easy to add later if there 's real demand [ 1 ] 
 Good eyes . Thanks ! 
 Yes , we agreed to remove the ' in ' operator as some kind of syntactic sugar . thanks 
 Thanks ! I pushed a small commit removing an " in " example .
Paragraph (version A):
The value of the first operand ("containable") of a "contain-expr"
is compared to every single element of the RHS "container".  In
case of a match a selection occurs.  Containment tests -- like
comparisons -- are restricted to primitive values.  So even if a
structured "containable" value is equal to a certain structured
value in "container", no selection is done.
Paragraph (version A):
The value of the second operand ("container") of a "contain-expr"
needs to be resolved to an array.  Otherwise nothing is selected.
Draft: draft-ietf-jsonpath-base

Commentary: 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 !
Paragraph (version A):
inspired-by-xpath provides a brief synopsis with XML's XPath XPath,
which was the inspiration that led to the definition of JSONPath.
Paragraph (version B):
inspired-by-xpath describes how JSONPath was inspired by XML's XPath
XPath.
Paragraph (version A):
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
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.
Paragraph (version B):
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
values with a constant.
Draft: draft-ietf-jsonpath-base

Commentary: ... 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 
 and 
 From the document : ( whitespace is now generally called blank space , but that does n'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 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 should n'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 are probably needed , either now or in a subsequent PR .
Paragraph (version A):
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
nodes: "{"b":0}", "{"b":1}", and "{"c":2}".
Paragraph (version B):
Next, "[*]" selects from any input node -- either an array or an
object -- all its elements or members.  The result is a list of three
nodes: "{"b":0}", "{"b":1}", and "{"c":2}".
Draft: draft-ietf-jsonpath-base

Commentary: 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 do n'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 does n't select the root node - it selects nodes within the current node as usual . 
 I agree . Paths like should be allowed , but would n'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 . 
 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 .
Paragraph (version A):
Discussion (D4): Is that a common requirement?  Or can a selector
also go up, or to the query argument?
Draft: draft-ietf-jsonpath-base

Commentary: I agree with this . Concatenation seems to always be the appropriate action here .
Paragraph (version A):
A selector performs its function on each of the nodes in its input
nodelist, during such a function execution, such a node is referred
to as the "current node".  Each of these function executions produces
a nodelist, which are then combined by algorithm _combine1_ into the
result of the selector.
Paragraph (version A):
Discussion (D2): We haven't decided yet whether there is only one
_combine1_ or a choice, with for instance simple concatenation and
concatenation with duplicate removal, based on a definition of
duplicate, are candidates.
Paragraph (version B):
A selector performs its function on each of the nodes in its input
nodelist, during such a function execution, such a node is referred
to as the "current node".  Each of these function executions produces
a nodelist, which are then concatenated into the result of the
selector.
Paragraph (version A):
But a selector doesn't just act on a single node: a selector acts on
each of the nodes in its input nodelist and selects an output
nodelist for each of them, as follows, which are then combined using
the combine1 algorithm to form the result nodelist of the selector.
Paragraph (version A):
Discussion (D3): Do we allow selectors that have their own
combine1 variant, or can we always use the same?
Paragraph (version B):
But a selector doesn't just act on a single node: a selector acts on
each of the nodes in its input nodelist and concatenates the
resultant nodelists to form the result nodelist of the selector.
Draft: draft-ietf-jsonpath-base

Commentary: 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 ca n'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  . 
 Yes absolutely ... I like that clean concept a lot .
Paragraph (version A):
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?