Draft: draft-normington-jsonpath-latest

Commentary: Start work on a merge of the two drafts . 
 Which one is that ? 
 You just answered it , thanks . 
 There are really two questions here : It was proposed by Goessner 's original post and supported by his libraries . That alone is a good argument , but additionally , it 's already supported by a large number of implementations in other langauges . Conversely , we may want to postpone inclusion of this for simplicity 's sake . Goessner 's original post ( 2007 ) described using JSONPath itself as the format used to indicate the position . The issue with using JSONPath is that it 's a query syntax , and while it can isolate a single value , it 's not specifically designed to . ( 2013 ) , however , was designed to isolate a single value within a JSON structure . It has other advantages as well : It 's a simple syntax . It 's already in a formal specification . It 's widely supported . Furthermore , it 's non - competitive with JSONPath because of its different intended purpose : isolating single values vs JSONPath 's querying for potentially multiple values . 
 Yes , we want to support this . We probably want to be able to support both applications that need a JSON Pointer and those that need a ( basic ) JSONPath query . One detail that we have to keep in mind is that it is easy to convert a ( basic ) JSONPath into a JSON Pointer , but not the other way around : interpreting a JSON Pointer needs to have the JSON value around so a path component can be disambiguated between a number ( array index ) and a string ( map key ) . These look the same in JSON Pointer but different in JSONPath . So it seems to me that we want to return JSONPath queries and not JSON Pointers , as the latter can easily be created from the former . 
 stating the conversion problem explicitly : the JSONPointer : finds in both following documents : and we do n't want this JSONPath to also locate in both documents ( that is , we do n't want JSONPath to stringify the numeric literal into a string literal , if applied to an object ) ? 
 Exactly . I do n't know whether there are JSONPath implementations where would return for your document 1 , or for your document 2 , but I think we want to keep these clearly separated for JSONPath , even if they are n't in JavaScript . 
 Fair enough . I 'm surprising myself about how easily I can wear the hat of somebody with no strong opinions on the semantics . That said , I do have opinions on how should we approach the specification , including the scope . The main reason for me to consider specifying JSONPath evaluation output in terms of pointers to values lies in its ability to clearly reason about query result duplicates . The actual format of the results seems to me more of an implementation detail , in the same way we 're not going to specify whether the result is a linked list of values or an array of values . Implementations should be free of emitting   JSONPointer outputs . But the specification could choose JSONPointer as the clearest means to an end : showing what it means to produce a result that points to values in the input document . 
 As a specification , we need to be prescriptive , choosing a single format . Our client is the consuming application , and requiring them to expect one of potentially multiple output formats is not ideal . An implementation is free to go above and beyond the specification and support both , but we definitely should n't : require support of both or give the option to support either as this adds burden to the consuming application . This is true for whichever location identifier syntax we choose . Remember , this is in the output result of a JSONPath evaluating an instance . Without the instance , the location loses all context , and whether a represents an integer index or a string property name becomes moot . You always need the instance to intepret the location , whether it 's expressed in JSON Pointer or JSONPath . JSONPath to stringify the 0 numeric literal into a " 0 " string literal , if applied to an object ) ? As above , this location identifier is intrinsicly linked to the instance that was evaluated . When a JSONPath is evaluated against instance A , it produces a set of location identifiers that are specific to that evaluation . If we then evaluate the same path against instance B , a different set of location identifiers are produced . The location identifiers produced by the evaluation of A are not relevant at all to B. It does n't make sense to talk about a numeric segment being interpreted an index or a key with different instances because the location identifier that contains that segment is tied to the instance that produced it . So ultimately the choice comes down to the following : Using JSONPath as the location identifier means that the logic to evaluate it is the same as the logic which produced it ( which is convenient ) . However evaluating the location identifier against the instance produces a single - value array , which suggests that multiple values could result . ( It also feels odd that this evaluation of the output path against the instance again produces the output path . ) Using JSON Pointer is more semantically appropriate since it only produces a single value . However it does require support of another syntax ( though that support will ideally be provided by a separate implementation , of which there are many in multiple languages ) . sounds like a vote for JSON Pointer to me . This is my vote as well . 
 Just to note , a common reason for users to want paths as an option is to perform diagnostics related to a query that returned values . For such users , JSONPath paths are needed , not something else . Also of note , Goessner refers to these paths as " normalized path expressions " , presumably intending them to be unique and identifying a single value . It is required that they use the bracket as opposed to the dot notation , but that is not enough , more restrictions are needed . It would be helpful if the specification preserved the term " normalized path expression " and formally defined it . 
 As in ? 
 It 'd be great if we could get an example of a case where a path would be required and a pointer would be insufficient . 
 Greg , any " normalized  expression " can be translated into a JSON pointer . If you have the instance handy , it can even be translated back ( more effort ) . To me it seems : it is easy to make a JSON Pointer out of a normalized   . the inverse is not so easy without following along in the argument . JSON pointers are great , but somewhat foreign in the JSONPath universe . To me , it seems to be unnecessary to drag in a different universe . JSONPath is sufficient , and the conversion towards   is a really small matter of programming ( that still could be a recommended component of a JSONPath library ) . 
 One random example I can think of : when all the user has is a JSONPath evaluator , and she wants to re - evaluate the output path against the input document without downloading a new library 
 I agree with this comment . 
 It would be interesting to survey some users and find out what they 're doing with the normalized path expressions . My impression is that some of them are performing diagnostics , and if you 're trying to understand the output of a JSONPath query , I think you 'd want to see JSONPath normalized path expressions rather than JSONPointer 's , I do n't think you 'd want to start seeing slashes and tildes . But it would be better to ask users . 
 Yes ! But in addition to stating what a " normalized path expression " is for ( identifies exactly one Position in an Argument ) , it should define what it is , perhaps , a JSONPath expression with the restriction that it uses the bracket notation exclusively ( no dot notation , no recursive descent notation , no filters , no function ) , no wildcards , no slices . I think those restrictions are enough to imply uniqueness . In addition , the specification should describe how a list of normalized path expressions can be generated given a JSONPath expression and a JSON instance . 
 Just a note on the limitations of normalized path expressions as the output of a JSONPath query . Implementations that support functions , and some important ones do , can not produce normalized path expressions as output if functions are applied to paths . For example , take , which supports functions that can be invoked at the tail end of a path , with input and path With " matching values " option , the result is But with " normalized path expressions " option , a diagnostic is issued 
 +1 
 +1 
 +1 . Let 's minimise ( a ) the dependencies and ( b ) the total surface area ( including dependencies ) of the spec . 
 Okay ... So I think it 's clear that   is not desired for this ( even though it 's already mentioned in the spec to declare that  is not an alternative for it ) . The main point of this issue was to determine if we want locations included in the output . Let 's keep focused on that , please . 
 Interesting discussion that is pretty much implemented ; might further inform , where this is referenced now .
Paragraph (version A):
JSONPath was introduced by Stefan Goessner as a simple form of XPath
for JSON.  See his original article Goessner.
Paragraph (version B):
This document picks up the popular JSONPath specification dated
2007-02-21 and provides a normative definition for it.  In its
current state, it is a strawman document showing what needs to be
covered.
Paragraph (version B):
Comments and issues can be directed at the github repository _insert
repo here_ as well as (for the time when the more permanent home is
being decided) at the dispatch@ietf.org mailing list.
Paragraph (version B):
This document picks up the popular JSONPath specification dated
2007-02-21 JSONPath-orig and provides a normative definition for it.
In its current state, it is a strawman document showing what needs to
be covered.
Paragraph (version A):
The syntax in this document conforms to ABNF as defined by RFC5234.
Paragraph (version A):
ABNF terminal values in this document define Unicode code points
rather than their UTF-8 encoding.  For example, the Unicode PLACE OF
INTEREST SIGN (U+2318) would be defined in ABNF as "%x2318".
Paragraph (version B):
The grammatical rules in this document are to be interpreted as ABNF,
as described in RFC5234.  ABNF terminal values in this document
define Unicode code points rather than their UTF-8 encoding.  For
example, the Unicode PLACE OF INTEREST SIGN (U+2318) would be defined
in ABNF as "%x2318".
Paragraph (version B):
The terminology of RFC8259 applies.
Paragraph (version B):
A structure complying to the generic data model of JSON, i.e.,
composed of containers such as arrays and maps (JSON objects), and
of atomic data such as null, true, false, numbers, and text
strings.
Paragraph (version B):
Used in its generic sense, e.g., for programming language objects.
When a JSON Object as defined in RFC8259 is meant, we specifically
say JSON Object.
Paragraph (version B):
Short name for JSONPath expression.
Paragraph (version B):
Short name for the JSON data item a JSONPath expression is applied
to.
Paragraph (version B):
A simple form of JSONPath expression that identifies a Position by
providing a query that results in exactly that position.  Similar
to, but syntactically different from, a JSON Pointer RFC6901.
Paragraph (version B):
A JSON data item identical to or nested within the JSON data item
to which the query is applied to, expressed either by the value of
that data item or by providing a JSONPath Output Path.
Paragraph (version B):
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 B):
Finding data interactively and extracting them out of RFC8259 data
items without special scripting.
Paragraph (version B):
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 B):
So what does such a tool look like for JSON?  When defining a
JSONPath, how should expressions look?
Paragraph (version B):
in popular programming languages such as JavaScript, Python and PHP,
with a variable x holding the JSON data item.  Here we observe that
such languages already have a fundamentally XPath-like feature built
in.
Paragraph (version B):
be naturally based on those language characteristics.
Paragraph (version B):
cover only essential parts of XPath 1.0.
Paragraph (version B):
be lightweight in code size and memory consumption.
Paragraph (version B):
be runtime efficient.
Paragraph (version B):
JSONPath expressions always apply to a JSON data item in the same way
as XPath expressions are used in combination with an XML document.
Since a JSON data item is usually anonymous and doesn't necessarily
have a "root member object", JSONPath used the abstract name "$" to
refer to the top level object of the data item.
Paragraph (version B):
for paths input to a JSONPath processor.  [1] Where a JSONPath
processor uses JSONPath expressions as output paths, these will
always be converted to the more general _bracket-notation_.  [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.
Paragraph (version B):
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 B):
JSONPath was originally designed to employ an _underlying scripting
language_ 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 B):
Here is a complete overview and a side by side comparison of the
JSONPath syntax elements with their XPath counterparts.
Paragraph (version B):
Square brackets in XPath expressions always operate on the _node
set_ resulting from the previous path fragment.  Indices always
start at 1.
Paragraph (version B):
With JSONPath, square brackets operate on the _object_ or _array_
addressed by the previous path fragment.  Array indices always
start at 0.
Paragraph (version B):
The examples in tbl-example use the expression mechanism to obtain
the number of items in an array, to test for the presence of a map
member, and to perform numeric comparisons of map member values with
a constant.
Paragraph (version A):
This memo includes no request to IANA.
Paragraph (version A):
All drafts are required to have an IANA considerations section (see
RFC5226 for a guide).  If the draft does not require IANA to do
anything, the section contains an explicit statement that this is the
case (as above).  If there are no requirements for IANA, the section
will be removed during conversion into an RFC by the RFC Editor.
Paragraph (version A):
This section gives security considerations, as required by RFC3552.
Paragraph (version B):
TBD: Define a media type for JSON Path expressions.