Code change:
1.2. <del> A frequently emphasized advantage of XML is the availability of powerful tools to analyse, transform and selectively extract data from XML documents.  XPath is one of these tools. </del> <ins> This document picks up Stefan Goessner's popular JSONPath specification dated 2007-02-21 JSONPath-orig and provides a normative definition for it. inspired-by-xpath provides a brief synopsis with XML's XPath XPath, which was the inspiration that led to the definition of JSONPath. JSONPath was intended as a light-weight companion to JSON implementations on platforms such as PHP and JavaScript, so instead of defining its own expression language like XPath did, JSONPath delegated this to the expression language of the platform.  While the languages in which JSONPath is used do have significant commonalities, over time this caused non-portability of JSONPath expressions between the ensuing platform-specific dialects. 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. </ins> <del> In 2007, the need for something solving the same class of problems for the emerging JSON community became apparent, specifically for: Finding data interactively and extracting them out of RFC8259 JSON values without special scripting. Specifying the relevant parts of the JSON data in a request by a client, so the server can reduce the amount of data in its response, minimizing bandwidth usage. So what does such a tool look like for JSON?  When defining a JSONPath, how should expressions look? The XPath expression looks like or in popular programming languages such as JavaScript, Python and PHP, with a variable x holding the argument.  Here we observe that such languages already have a fundamentally XPath-like feature built in. The JSONPath tool in question should: be naturally based on those language characteristics. cover only essential parts of XPath 1.0. be lightweight in code size and memory consumption. </del> <ins> 1.3. </ins> <del> be runtime efficient. </del> <ins> JSONPath expressions are applied to a JSON value, the </ins> <del> 1.3. </del> <ins> .  Within the JSONPath expression, the abstract name "$" is used to refer to the </ins> <del> JSONPath expressions always apply to a value in the same way as XPath expressions are used in combination with an XML document.  Since a value is anonymous, JSONPath uses the abstract name "$" to refer to the root node of the argument. </del> <ins> of the argument, i.e., to the argument as a whole. </ins> JSONPath expressions can use the or the <del> for paths input to a JSONPath processor.  [1] Where a JSONPath processor uses JSONPath expressions as output paths, these will always be converted to Output Paths which employ the more general .  [2] Bracket notation is more general than dot notation and can serve as a canonical form when a JSONPath processor uses JSONPath expressions as output paths. JSONPath allows the wildcard symbol "*" for member names and array indices.  It borrows the descendant operator ".." from E4X and the array slice syntax proposal "[start:end:step]" SLICE from ECMASCRIPT 4. JSONPath was originally designed to employ an </del> <ins> to build paths that are input to a JSONPath processor.  Bracket notation is more general than dot notation and can serve as a canonical form (for instance, when a JSONPath processor uses JSONPath expressions as output paths). </ins> <del> for computing expressions.  The present specification defines a simple expression language that is independent from any scripting language in use on the platform. </del> <ins> JSONPath allows the wildcard symbol "*" to select any member of an object or any element of an array (wildcard).  The descendant operator ".." selects the node and all its descendants (descendant- selector).  The array slice syntax "[start:end:step]" allows selecting a regular selection of an element from an array, giving a start position, an end position, and possibly a step value that moves the position from the start to the end (slice). </ins> <del> JSONPath can use expressions, written in parentheses: "(<expr>)", as an alternative to explicit names or indices as in: </del> <ins> JSONPath employs an </ins> <del> The symbol "@" is used for the current node.  Filter expressions are supported via the syntax "?(<boolean expr>)" as in </del> <ins> 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]: </ins> <del> Here is a complete overview and a side by side comparison of the JSONPath syntax elements with their XPath counterparts. </del> <ins> The symbol "@" is used for the current node, i.e., the node in the context of which the expression is evaluated. </ins> <del> XPath has a lot more to offer (location paths in unabbreviated syntax, operators and functions) than listed here.  Moreover there is a significant difference how the subscript operator works in Xpath and JSONPath: </del> <ins> Filter expressions are supported via the syntax "?(<boolean expr>)" as in </ins> <del> Square brackets in XPath expressions always operate on the resulting from the previous path fragment.  Indices always start at 1. With JSONPath, square brackets operate on the or addressed by the previous path fragment.  Array indices always start at 0. </del> <ins> tbl-overview provides a quick overview of the JSONPath syntax elements. </ins> 2.

Related discussion:
text: Thanks for merging. I had a small fix to the caption of table 1 which is now .
(This was original raised in and now being split out) (Michael Kay) want to confuse the JSONPath spec by going into detailed comparisons at the risk of contradicting the normative text. (Glyn Normington) (Michael Kay) It seemed to be important in 2007, while argumenting to have something like XPath for JSON. If nowadays the terminology used has changed significantly with XPath 2.0 and 3.0, we better leave that comparison table 2 out. I am quite passionless here. At the IETF 110 meeting consensus was raised that inclusion of XPath in the Appendix section would be the most appropriate way to reference to it.
Closed in
Great improvement!Additions / Replacements of high value ... thanks