Subject: [apps-discuss] JSON Pointer syntax

From: Evan Prodromou <[email-masked]>
Date: Wed, 19 Sep 2012 11:16:56 -0400

I find it funny that JSON Pointer syntax doesn't map more closely to 
object syntax in JavaScript.

I'd expect that {"foo": {"bar": {"baz": 2}}} would be addressed as 
something familiar like "foo.bar.baz" rather than "foo/bar/baz", and 
{"foo": {"bar.baz": 2}} would be addressed as something like 
'foo["bar.baz"]'.

I've seen the dotted notation in other contexts, like MongoDB queries:

http://www.mongodb.org/display/DOCS/Advanced+Queries#AdvancedQueries-ValueinanEmbeddedObject

-Evan

---

From: Francis Galiegue <[email-masked]>
Date: Wed, 19 Sep 2012 17:27:44 +0200

On Wed, Sep 19, 2012 at 5:16 PM, Evan Prodromou <[email-masked]> wrote:
> I find it funny that JSON Pointer syntax doesn't map more closely to object
> syntax in JavaScript.
>

JSON is not JavaScript!

/ has been chosen because it is the most commonly used path separator,
and note as well that JSON Pointer does not make differences between
objects and arrays.

> I'd expect that {"foo": {"bar": {"baz": 2}}} would be addressed as something
> familiar like "foo.bar.baz" rather than "foo/bar/baz", and {"foo":
> {"bar.baz": 2}} would be addressed as something like 'foo["bar.baz"]'.
>

That'd be "/foo/bar/baz" (note the initial /) and "/foo/bar.baz".
Unambiguous, unlike your notation.

And accessing the first element of this array:

[ 1, 2, 3 ]

is written /0. So is accessing key 0 in this object:

{ "0": 1 }

JSON Pointer has been written like this on purpose. It is unambiguous,
impervious to programming languages pecularities and encodings... All
advantages and none of the drawbacks :)

-- 
Francis Galiegue, [email-masked]
JSON Schema: https://github.com/json-schema
"It seems obvious [...] that at least some 'business intelligence'
tools invest so much intelligence on the business side that they have
nothing left for generating SQL queries" (Stéphane Faroult, in "The
Art of SQL", ISBN 0-596-00894-5)

---

From: Evan Prodromou <[email-masked]>
Date: Wed, 19 Sep 2012 12:06:14 -0400

> advantages and none of the drawbacks :) 
It conspicuously lacks the advantage of being familiar for people who 
know JavaScript or JavaScript-based syntaxes like the MongoDB example I 
linked to.

That said, I appreciate the response, and I'm just glad the subject has 
been discussed.

-Evan

---

From: Francis Galiegue <[email-masked]>
Date: Wed, 19 Sep 2012 18:44:44 +0200

On Wed, Sep 19, 2012 at 6:06 PM, Evan Prodromou <[email-masked]> wrote:
> It conspicuously lacks the advantage of being familiar for people who know
> JavaScript or JavaScript-based syntaxes like the MongoDB example I linked
> to.
>

Sure, but again, JSON Pointer has not been conceived with any
programming language in mind. It, and JSON Reference, are the only two
existing mechanisms able to unambiguously address any subset of any
JSON value anywhere, by anyone, at any time.

Tying this kind of specification to a programming language/a
particular protocol/whatever would be shortsighted and
counterproductive. And consider this:

{ "": { "/": { "~": [ 1, 2 ] } } }

With JSON Pointer, you address the first element of the inner array
using //~0/~1/0. This is even shorter to write than it is in
JavaScript. _And_ more portable ;)

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 19 Sep 2012 12:59:17 -0400

On Wed, Sep 19, 2012 at 12:44 PM, Francis Galiegue <[email-masked]>wrote:

> know

Just where is JSON Pointer intended to be used? Who is using it?

Pretty much every modern programming language has adopted a notation that
uses dots for member extraction and square braces for array indices. I
don't see a particularly good reason to invent another way to extract
information from a data structure.

In C# and Java the notation would be x.y[1].

There are different answers in C and C++ of course but I don't think anyone
wants to copy from those examples at this point.

Trying to use all dots comes up with the problem that x and y are labels
and an array index is a value so using a format like x.y.1 becomes
difficult to interpret when using a variable for an index, x.y.z is
confusing as x and y are member names and z is an index. This gets even
worse when z is also a member name (and could lead to attacks).

I can't see why I would want to have a different syntax to extract elements
after a data object has been JSON encoded. What is the value of such a
standard meant to be?

This looks like an attempt to reinvent a wheel that has already been tried
and tested.

-- 
Website: http://hallambaker.com/

---

From: Francis Galiegue <[email-masked]>
Date: Wed, 19 Sep 2012 19:05:16 +0200

On Wed, Sep 19, 2012 at 6:59 PM, Phillip Hallam-Baker <[email-masked]> wrote:
[...]
> Just where is JSON Pointer intended to be used? Who is using it?

JSON Schema, for instance, even though only implicitly for now. The
next version will mandate JSON Reference support and, as such, JSON
Pointer (which is the fragment part of a JSON Reference).

> uses dots for member extraction and square braces for array indices. I don't
> see a particularly good reason to invent another way to extract information
> from a data structure.
>

Again, programming languages do not enter the picture. What is wanted
is an unambiguous way to address any part of a JSON value.

Oh, and "." is a valid object member name. And so is "/" for that
matter. And so is "", and so is "\x00".

[...]
> after a data object has been JSON encoded. What is the value of such a

Language-proof, future-proof, covers all corner cases. If these are
not arguments, I don't know what is.

Oh, and the fact that it can be used in URI fragments.

> This looks like an attempt to reinvent a wheel that has already been tried

Tried and tested _by a few subset of programming languages_.

---

From: James M Snell <[email-masked]>
Date: Wed, 19 Sep 2012 10:39:02 -0700

In general, I agree. While simple, the existing JSON Pointer syntax is not
particularly good and does not appear to have any advantage over existing
JavaScript syntax except, perhaps when it comes to handling escaped
characters (as Francis points out).

For example, JSON Pointer is currently used by the JSON Patch specification
to reference locations within a JSON document that is being modified.

Supposing the following example document,

  {
    "a": {
      "b": {
        "c": "test",
        "d": [1,2,3]
      }
    }
  }

Using JSON Patch, I can describe a number of changes to make to this
document:

  [
    {"replace":"/a/b/c", "value": "foobar" },
    {"move":"/a/b/c", "to": "/c" },
    {"move":"/a/b/d/0, "to": "/a/b/c/1" }
  ]

After applying these changes, the document would be:

  {
    "a": {
      "b": {
        "d": [2,1,3]
      }
    },
    "c": "foobar"
  }

Using a dot syntax instead of the slashes demonstrates that there is really
nothing gained by the slashes.

  [
    {"replace":"a.b.c", "value": "foobar" },
    {"move":"a.b.c", "to": "c" },
    {"move":"a.b.d[0]", "to": "a.b.d[1]" }
  ]

With regards to oddly named members (e.g. "."), the existing JSON Pointer
syntax does provide a bit of a simplicity advantage. For instance, given
the following exceedingly awful but perfectly valid JSON document:

  {
    ".": {
      "/": {
        "": ["foo"]
      }
    }
  }

The current JSON Pointer syntax for referencing the "foo" value would be:

  /./~1//0

Using JavaScript notation, however, it would be something along the lines
of...

  ["."]["/"][""][0]

To be fair, both are ugly. The former is less complicated lexically but the
latter has the advantage of being directly processable within multiple
languages without any special handling. For example:

  # Ruby
  require 'json'
  m = JSON.parse('{".":{"/":{"":["foo"]}}}')
  m["."]["/"][""][0]

It Just Works(tm), right out of the box.

Where the JavaScript syntax falls down, of course, is when the Pointer is
to be used as a component of a URI... which, of course, is one of the major
motivating use cases for JSON Pointer in the first place. Obviously, the
square brackets [ and ] are explicitly required to be pct-encoded within a
URI, making the URI significantly less than human readable.

http://example.org/foo.json#%5B%22.%22%5D%5B%22%2F%22%5D%5B%22%22%5D%5B0%5D

As opposed to:

  http://example.org/foo.json#/./~1//0

In short, there are obvious advantages and disadvantages to either syntax
approach. Personally, I'd tend to favor the JavaScript syntax because it's
easier to process despite being more verbose, but the slash syntax is
simple and get's the job done.

- James

On Wed, Sep 19, 2012 at 9:59 AM, Phillip Hallam-Baker <[email-masked]>wrote:

> There are different answers in C and C++ of course but I don't think
> anyone wants to copy from those examples at this point.
>
> I can't see why I would want to have a different syntax to extract
> elements after a data object has been JSON encoded. What is the value of
> such a standard meant to be?
>
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 19 Sep 2012 10:44:36 -0700

On 19/09/2012, at 10:39 AM, James M Snell <[email-masked]> wrote:

> In short, there are obvious advantages and disadvantages to either syntax approach. Personally, I'd tend to favor the JavaScript syntax because it's easier to process despite being more verbose, but the slash syntax is simple and get's the job done. 

So, this is a great conversation, but without someone sitting down and writing the specification text, verifying that it behaves well in various languages (so that we don't leave attractive nuisances around -- a significant risk when you specify something that *looks* like it should work "out of the box"), and proposes it to the group, I don't see where it's going.

Any takers?

--
Mark Nottingham
http://www.mnot.net/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 19 Sep 2012 13:45:11 -0400

It seems to me that if unrestricted chars are permitted, a simpler approach
would be to require tags to be specified as JSON strings.

"a"."b"."/"

That approach supports any tag that is a legal JSON tag including dots.

As an option, the encoding could permit the quotes to be omitted if the
label only consisted of 'safe' characters. i.e. a-z, A-Z, 0-9, -, _ and any
UNICODE char > 255.

On Wed, Sep 19, 2012 at 1:39 PM, James M Snell <[email-masked]> wrote:

> For example, JSON Pointer is currently used by the JSON Patch
> specification to reference locations within a JSON document that is being
> modified.
>
> Using a dot syntax instead of the slashes demonstrates that there is
> really nothing gained by the slashes.
>
>   [
> To be fair, both are ugly. The former is less complicated lexically but
> the latter has the advantage of being directly processable within multiple
>> This looks like an attempt to reinvent a wheel that has already been
>> tried and tested.
>>
>> --

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 19 Sep 2012 13:48:02 -0400

I have _a_ schema proposal that does just that but is not limited to JSON.
I have mappings for C# and I have a tool chain that allows people to play
around and extend the mapping for their own favorite language pretty easily.

Seems to me that looking at all the 'REST' protocols that use url forms
encoding for requests, a JSON schema that does not also address forms
encoding is not going to be particularly useful.

On Wed, Sep 19, 2012 at 1:44 PM, Mark Nottingham <[email-masked]> wrote:

> > In short, there are obvious advantages and disadvantages to either
> syntax approach. Personally, I'd tend to favor the JavaScript syntax
> because it's easier to process despite being more verbose, but the slash
> syntax is simple and get's the job done.
>
> So, this is a great conversation, but without someone sitting down and
> writing the specification text, verifying that it behaves well in various
> languages (so that we don't leave attractive nuisances around -- a
> significant risk when you specify something that *looks* like it should
> work "out of the box"), and proposes it to the group, I don't see where
> it's going.
>
> Any takers?
>
>
> --
> Mark Nottingham
> http://www.mnot.net/
>
>
>
>
>

---

From: "Paul C. Bryan" <[email-masked]>
Date: Wed, 19 Sep 2012 10:55:37 -0700

For fun reading—and a bit of a history lesson—see
http://tools.ietf.org/html/draft-pbryan-json-patch-00 and check out its
proposed path notation. Path/pointer notation was then discussed a fair
amount, and slash notation would up being favoured over the dot/bracket
notation.  

Paul

---

From: James M Snell <[email-masked]>
Date: Wed, 19 Sep 2012 11:05:09 -0700

Paul, do you happen to have a link referencing the path/pointer discussion
readily available? I (and I'm sure others) would appreciate being able to
review what specific arguments were made. I could go hunting for them
myself but figured it might be faster just to ask.

On Wed, Sep 19, 2012 at 10:55 AM, Paul C. Bryan <[email-masked]> wrote:

> **
> apps-discuss mailing [email-masked]://www.ietf.org/mailman/listinfo/apps-discuss
>
>
>

---

From: "Paul C. Bryan" <[email-masked]>
Date: Wed, 19 Sep 2012 11:24:32 -0700

I don't have a specific thread in hand I can point you to right now.
Back in the early days, the lists we discussed this on were: JSON
Schema, JSON Patch and CouchDB. I can probably (later) also dig-up some
email exchanges with Kris Zyp regarding his decision to abandon dot
notation in favour of slash.

Paul

On Wed, 2012-09-19 at 11:05 -0700, James M Snell wrote:
> Paul, do you happen to have a link referencing the path/pointer
> discussion readily available? I (and I'm sure others) would appreciate
> being able to review what specific arguments were made. I could go
> hunting for them myself but figured it might be faster just to ask.
> 
>         http://tools.ietf.org/html/draft-pbryan-json-patch-00 and
>         check out its proposed path notation. Path/pointer notation
>         was then discussed a fair amount, and slash notation would up
>         being favoured over the dot/bracket notation.  
>         
>         Paul
>         
>

---

From: Evan Prodromou <[email-masked]>
Date: Thu, 20 Sep 2012 06:36:26 -0400

Thanks! Good link here, too:

http://goessner.net/articles/JsonPath/

-Evan

On 12-09-19 01:55 PM, Paul C. Bryan wrote:
> http://tools.ietf.org/html/draft-pbryan-json-patch-00 and check out 
> its proposed path notation. Path/pointer notation was then discussed a 
> fair amount, and slash notation would up being favoured over the 
> dot/bracket notation.
>
> Paul
>
>> [email-masked]  <mailto:[email-masked]>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 20 Sep 2012 09:04:41 -0400

The notation here does look easier to understand than the slashes. Though
they don't seem to appreciate that you need dots and brackets for different
purposes. A member label and an array index are two very different things
and the syntax should differentiate between them.

But there still seems to be the approach of 'lets copy all the
functionality of XPath' rather than 'how much XPath functionality is
actually necessary'.

Might just be a bias on my part here but my college tutor was Tony Hoare
and so the idea that you can improve a language by taking unnecessary stuff
out tends to come to mind. I don't think we can improve JSON by repeating
all the mistakes of XML.

I consider the ability to reference a sub-structure to be a programming
language concern rather than a data format concern. So the dot notation
looks better from that point of view. But programming language bindings
don't need to be standardized across languages. If I am writing in C# then
it would make sense to use the C# path extractor which might be very
different from the Perl or Python extractor (but will probably be the same)

The main reason for preferring the dot notation is that the slash character
is a reserved character in URLs, in particular HTTP URLs.

The only case where I see a need for an interoperable standard is if the
path identifier is being used in a  URL query or fragment

http://www.example.com/whatever?<path-expression>

or

http://www.example.com/whatever#<path-expression>

Now fragment identifiers are actually a document format thing and I need to
chase down the reference for it but the slash character is quite definitely
reserved in <path-expression>. So it would have to be escaped. Given the
choice of a character that has to be escaped vs one that does not we take
the one that does not.

Array indices are more problematic as [ and ] were declared 'unsafe'. I am
not sure that they really are unsafe at this point. ( and ) should be safe
but using them instead of the familiar indexes can be confusing.

The trickiest part is dealing with the fact that JSON tags can include any
character at all and the quoting characters " and ' are definitively
unsafe. One approach would be to 'simply' decide that the quotes can be
omitted if no ambiguity arises and that the tags much be quoted otherwise.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 20 Sep 2012 15:25:33 +0200

On 2012-09-20 15:04, Phillip Hallam-Baker wrote:
> The notation here does look easier to understand than the slashes.
> Though they don't seem to appreciate that you need dots and brackets for
> different purposes. A member label and an array index are two very
> different things and the syntax should differentiate between them.

Does it need to?

> functionality of XPath' rather than 'how much XPath functionality is

How so, except for the choice of separators?????

> and so the idea that you can improve a language by taking unnecessary
> stuff out tends to come to mind. I don't think we can improve JSON by
> repeating all the mistakes of XML.

I don't think this is the case here at all.

> don't need to be standardized across languages. If I am writing in C#
> then it would make sense to use the C# path extractor which might be
> very different from the Perl or Python extractor (but will probably be
> the same)
>
> The main reason for preferring the dot notation is that the slash
> character is a reserved character in URLs, in particular HTTP URLs.

How is that a problem? It's reserved for hierarchical notations, and 
that's exactly what it's been used for here.

> http://www.example.com/whatever#<path-expression>

The main use case I see actually is

http://www.example.com/<path-expression>

> ...

Best regards, Julian

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 20 Sep 2012 10:07:44 -0400

>> different things and the syntax should differentiate between them.

Yes, it does consider:

{ "alice" : { "bob" : [ 10, 20, 30] } }

Let us imagine we have code that is stepping through each element of an
array using an index i. The path looks like  alice.bob.i

Iterating the loop produces 10, 20, 30

When evaluating that expression in a scripting language or such we have
alice and bob which are tag names and we have i which is a bound variable
being used as an index. That leads to confusion.

Now imagine that mallet knows that the index variable used is i, she
creates the following message:

{ "alice" : { "bob" : [ 10, 20, 30] , "i" : 42 } }

Depending on the implementation the iteration may now produce 10, 20, 30 as
before or 42 or even 42, 42, 42.

This is why languages like Java and C# kept the concept of array indices
when the jettisoned all the rest of the baroque C++ syntax. It is an
important difference with real security implications.

This is also why folk like me never want to use type unsafe scripting
languages designed by people who didn't appreciate this type of issue.

> How so, except for the choice of separators?????

Reading the original post cited, the author suggests that XPath
functionality is the goal. It really should not be.

> that's exactly what it's been used for here.

No, it is RESERVED as in do not use it after the query.

We are not talking about a change to the HTTP URL spec here. So we MUST NOT
use that character. It is out of bounds.

>> http://www.example.com/**whatever <http://www.example.com/whatever>
>> ?<path-expression>
>>
>> or
>>
>> http://www.example.com/**whatever# <http://www.example.com/whatever#>
>> <path-expression>
>>
>
> http://www.example.com/<path-**expression>
>

OK, if you are going to do that then you can use the / separator.  But I
rather suspect that not distinguishing the boundary between the file system
and the document is going to be problematic. There may even be security
issues.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 20 Sep 2012 16:15:47 +0200

On 2012-09-20 16:07, Phillip Hallam-Baker wrote:
>
>
> On Thu, Sep 20, 2012 at 9:25 AM, Julian Reschke <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> alice and bob which are tag names and we have i which is a bound
> variable being used as an index. That leads to confusion.
>
> Depending on the implementation the iteration may now produce 10, 20, 30
> as before or 42 or even 42, 42, 42.
>

Well, JSON Pointer has:

    If a reference token is being evaluated against a JSON document,
    implementations will evaluate each token against the document's
    contents, and terminate evaluation with an error condition if it
    fails to resolve a concrete value for any of the JSON pointer's
    reference tokens.  See Section 7 for details.

So for any given pointer and object syntax, it's clear whether it's an 
array or not.

> functionality is the goal. It really should not be.

I personally think that XPath is awesome. But that being said, JSON 
Pointer as specified in the internet draft is really only a sequence of 
identifiers separated by "/". That's it. I don't think it is productive 
to question things that are actually not in the Internet Draft-

> We are not talking about a change to the HTTP URL spec here. So we MUST
> NOT use that character. It is out of bounds.

BS. Nobody is proposing to change the URI syntax, which happens to say:

    query       = *( pchar / "/" / "?" )

(<http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.3.4>).

>         http://www.example.com/__whatever
>         <http://www.example.com/whatever>?<path-expression>
>
>         or
>
>         http://www.example.com/__whatever#
>         <http://www.example.com/whatever#><path-expression>
>
>
>     http://www.example.com/<path-__expression>
>
>
> rather suspect that not distinguishing the boundary between the file
> system and the document is going to be problematic. There may even be
> security issues.

There's no "file system" in my server. And even if there was, it 
wouldn't matter because we're defining message formats and identifier 
syntax, not how a server implements those.

And yes, there are always security issues.

Best regards, Julian

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 20 Sep 2012 10:58:59 -0400

On Thu, Sep 20, 2012 at 10:15 AM, Julian Reschke <[email-masked]>wrote:

>> <mailto:[email-masked]>**> wrote:
>>

I do not understand that text. It is completely opaque to me. Or rather, I
cannot decide on one single unambiguous interpretation.

I certainly don't see it as something that can be quoted to resolve
ambiguity of the type I raised. Which one of the outcomes do you think it
requires? I certainly can't tell and I have a doctorate on formal methods.
So if I can't tell I think the likelihood of the statement meaning
something to an implementer is rather small.

> So for any given pointer and object syntax, it's clear whether it's an

How do you resolve the example I quote?

I am asking questions of interpretation here and your response is always
'go read the spec'. Well that is the whole issue, the spec is not clear and
it cannot be clear on this issue unless it raises it and addresses it as a
specific case.

If people can't explain how a spec should be interpreted then the spec
fails.

And yes, I have had to redesign a protocol because I could not explain
something clearly more often than I can recall.

> identifiers separated by "/". That's it. I don't think it is productive to
> question things that are actually not in the Internet Draft-

It is awesomely powerful if you need power. As a mechanism for identifying
sections of a document covered by XML Signature it is a catastrophe.

>    query       = *( pchar / "/" / "?" )

It goes on to say:

The characters slash ("/") and question mark ("?") may represent data
within the query component. Beware that some older, erroneous
implementations may not handle such data correctly when it is used as the
base URI for relative references (Section
5.1<http://greenbytes.de/tech/webdav/rfc3986.html#base-uri>),
apparently because they fail to distinguish query data from path data when
looking for hierarchical separators. However, as query components are often
used to carry identifying information in the form of "key=value" pairs and
one frequently used value is a reference to another URI, it is sometimes
better for usability to avoid percent-encoding those characters.

This would not be something I would see as critical if there was not
another choice here.

Probably the safest approach is to permit either separator to be used in
the path expression and make them interchangeable which is what we did with
" and '.

That still leaves the question of what to do with []. It looks like they
should be safe but it is something I would want to see tested.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 20 Sep 2012 17:13:21 +0200

On 2012-09-20 16:58, Phillip Hallam-Baker wrote:
>
>
> On Thu, Sep 20, 2012 at 10:15 AM, Julian Reschke <[email-masked]
>         On Thu, Sep 20, 2012 at 9:25 AM, Julian Reschke
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>__>
>         wrote:
>

How so? There's is only one object named "alice.bob" here, and it is an 
array. There's also "alice.i", but how does that matter?

> I do not understand that text. It is completely opaque to me. Or rather,
> I cannot decide on one single unambiguous interpretation.
>
> ambiguity of the type I raised. Which one of the outcomes do you think
> it requires? I certainly can't tell and I have a doctorate on formal
> methods. So if I can't tell I think the likelihood of the statement
> meaning something to an implementer is rather small.
>
>     So for any given pointer and object syntax, it's clear whether it's
>     an array or not.
>
>

I don't understand your example. Can you rephrase it in a way so that it 
becomes a question about JSON Pointer?

> 'go read the spec'. Well that is the whole issue, the spec is not clear
> and it cannot be clear on this issue unless it raises it and addresses
> it as a specific case.
>
>     Pointer as specified in the internet draft is really only a sequence
>     of identifiers separated by "/". That's it. I don't think it is
>     productive to question things that are actually not in the Internet
>     Draft-
>
>
> It is awesomely powerful if you need power. As a mechanism for
> identifying sections of a document covered by XML Signature it is a
> catastrophe.

Maybe. Is this a problem of XPath or XML Signature?

> implementations may not handle such data correctly when it is used as
> the base URI for relative references (Section 5.1
> <http://greenbytes.de/tech/webdav/rfc3986.html#base-uri>), apparently
> because they fail to distinguish query data from path data when looking
> for hierarchical separators. However, as query components are often used
> to carry identifying information in the form of "key=value" pairs and

I don't see it as critical.

> the path expression and make them interchangeable which is what we did
> with " and '.

I don't believe that allowing two different notations is actually helpful.

> should be safe but it is something I would want to see tested.

That would be relevant if JSON Pointer actually needed them. They are in 
RFC 3986's gen-delims, so strict URI parsers are likely to be unhappy 
when seeing them in unescaped form (in the wrong place).

Best regards, Julian

Best regards, Julian

---

From: James M Snell <[email-masked]>
Date: Thu, 20 Sep 2012 09:24:44 -0700

>>         array using an index i. The path looks like  alice.bob.i
Huh? If we're iterating through this using JavaScript code it would be
something like

  for (i in m.alice.bob)
    print(m.alice.bob[i]

If I was going to use a JSON Pointer to iterate through, it would look like

  for (i in m.alice.bob)
    print(eval_pointer( "m.alice.bob." + i ))

>>         variable being used as an index. That leads to confusion.
I'm sorry, but there is no confusion when the code example actually makes
sense. No disrespect intended, but the example you give here, Phil, does
not appear to make much sense.

> array. There's also "alice.i", but how does that matter?
The full set of valid JSON Pointers I see in this example are:

  /alice
  /alice/bob
  /alice/bob/0
  /alice/bob/1
  /alice/bob/2
  /alice/i

Which in dot notation, of course, would be:

  alice
  alice.bob
  alice.bob.0
  alice.bob.1
  alice.bob.2
  alice.i

I see absolutely no confusion here.

>  [snip]
Yes.. and again, no disrespect intended here Phil, but I think the issue at
hand right now is that, so far, none of the examples and feedback you have
provided, thus far, have made any sense at all.

> [snip]
>> <http://greenbytes.de/tech/**webdav/rfc3986.html#base-uri<http://greenbytes.de/tech/webdav/rfc3986.html#base-uri>
>> >)**, apparently
>>
+1 .. Pick One.

> RFC 3986's gen-delims, so strict URI parsers are likely to be unhappy when
> seeing them in unescaped form (in the wrong place).
>
>
I have run into a number of very real issues in various places with the use
of errant square brackets in query string parameters and fragment
identifiers. 3986 is actually quite clear on the fact that square brackets
are ONLY allowed when delimiting IPv6 addresses.

Specifically, section 3.2.2:

   A host identified by an Internet Protocol literal address, version 6
   [RFC3513] or later, is distinguished by enclosing the IP literal
   within square brackets ("[" and "]").  This is the only place where
   square bracket characters are allowed in the URI syntax.

I'll say again that I personally prefer the JavaScript notation, even with
square brackets and I don't generally see a problem with escaping those
within the URI. But the square brackets are not strictly required to make
things work. The existing / delimited syntax does work in practice and it's
simple to implement.

- James

> Best regards, Julian
>
>
> Best regards, Julian
>
> ______________________________**_________________
> https://www.ietf.org/mailman/**listinfo/apps-discuss<https://www.ietf.org/mailman/listinfo/apps-discuss>
>

---

From: Nico Williams <[email-masked]>
Date: Fri, 21 Sep 2012 11:57:40 -0500

> I find it funny that JSON Pointer syntax doesn't map more closely to object

Why not pile on?  Allow me to list my problems with JSON Pointer:

 - if it's meant to be XPath-like then call it JPath

 - ~0 and ~1 are not exactly great escapes for ~ and /, no, they're *awful*!

   Use ~/ and ~~, but not digits (and not even numbers corresponding
   to the Unicode or ASCII codepoints for these characters!).

 - Empty key string selection needs to be more obvious.

   The example given in the I-D is that "/" selects the value of the one
   key of the root object that is an empty string.  WAT?  That's not
   even remotely obvious.

 - Yeah, JSON Pointer is very limited by comparison to XPath 2.0, but
   please make it extensible so that it could get that powerful.

Nico
--