Draft: draft-ietf-jsonpath-base

Commentary: 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 ) (   ) want to confuse the JSONPath spec by going into detailed comparisons at the risk of contradicting the normative text . (   ) (   ) 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  section would be the most appropriate way to reference to it . 
 Closed in 
 Great improvement!Additions / Replacements of high value ... thanks
Paragraph (version A):
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.
Paragraph (version A):
Finding data interactively and extracting them out of RFC8259 JSON
values without special scripting.
Paragraph (version A):
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.
Paragraph (version A):
So what does such a tool look like for JSON?  When defining a
JSONPath, how should expressions look?
Paragraph (version A):
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.
Paragraph (version A):
be naturally based on those language characteristics.
Paragraph (version A):
cover only essential parts of XPath 1.0.
Paragraph (version A):
be lightweight in code size and memory consumption.
Paragraph (version A):
be runtime efficient.
Paragraph (version A):
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.
Paragraph (version A):
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.
Paragraph (version A):
for computing expressions.  The present specification defines a
simple expression language that is independent from any scripting
language in use on the platform.
Paragraph (version A):
Here is a complete overview and a side by side comparison of the
JSONPath syntax elements with their XPath counterparts.
Paragraph (version A):
resulting from the previous path fragment.  Indices always start
at 1.
Paragraph (version A):
addressed by the previous path fragment.  Array indices always
start at 0.
Paragraph (version B):
This document picks up Stefan Goessner's popular JSONPath
specification dated 2007-02-21 JSONPath-orig and provides a normative
definition for it.
Paragraph (version B):
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):
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.
Paragraph (version B):
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):
of the argument, i.e., to the argument as a whole.
Paragraph (version B):
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).
Paragraph (version B):
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).
Paragraph (version B):
The symbol "@" is used for the current node, i.e., the node in the
context of which the expression is evaluated.
Paragraph (version B):
tbl-overview provides a quick overview of the JSONPath syntax
elements.
Paragraph (version A):
The "descendant-selector" is inspired by ECMAScript for XML (E4X).
It selects the node and all its descendants.
Paragraph (version B):
The "descendant-selector" selects the node and all its descendants.