Subject: [apps-discuss] Last Call: <draft-ietf-appsawg-json-pointer-07.txt> (JSON Pointer) to Proposed Standard

From: The IESG <[email-masked]>
Date: Tue, 11 Dec 2012 07:00:57 -0800

The IESG has received a request from the Applications Area Working Group
WG (appsawg) to consider the following document:
- 'JSON Pointer'
  <draft-ietf-appsawg-json-pointer-07.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2012-12-25. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   JSON Pointer defines a string syntax for identifying a specific value
   within a JSON document.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-pointer/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: "Markus Lanthaler" <[email-masked]>
Date: Fri, 14 Dec 2012 11:51:10 +0100

I've asked that before but didn't get an answer. So let me ask again (even
though I'm quite sure it has already been asked by somebody else).

How does JSON Pointer distinguish between objects and arrays? E.g. consider
the following JSON document:

{
  "foo": "bar",
  "1": "baz"
}

As I read the draft, the JSON Pointer "/1" would evaluate to "baz" even
though that's probably not what the author intended. Is there a way to avoid
that?

Thanks,
Markus

--
Markus Lanthaler
@markuslanthaler

> -----Original Message-----
> From: [email-masked] [mailto:apps-discuss-
> [email-masked]] On Behalf Of The IESG
> Sent: Tuesday, December 11, 2012 4:01 PM
> To: IETF-Announce
> Cc: [email-masked]
> Subject: [apps-discuss] Last Call: <draft-ietf-appsawg-json-pointer-
> 07.txt> (JSON Pointer) to Proposed Standard
> 
> 
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: James M Snell <[email-masked]>
Date: Fri, 14 Dec 2012 08:40:36 -0800

JSON Pointer does not distinguish between objects and arrays. That is not
determined until the pointer is applied to an actual object instance... the
pointer "/1" is valid against {"1":"a"} or ["a","b"]

---

From: "Markus Lanthaler" <[email-masked]>
Date: Fri, 14 Dec 2012 18:17:33 +0100

Hmm.. I think that’s quite problematic. Especially considering how JSON Pointer is used in JSON Patch.

--

Markus Lanthaler

@markuslanthaler

From: James M Snell [mailto:[email-masked]] 
Sent: Friday, December 14, 2012 5:41 PM
To: Markus Lanthaler
Cc: IETF Discussion; IETF Apps Discuss
Subject: Re: [apps-discuss] Last Call: <draft-ietf-appsawg-json-pointer-07.txt> (JSON Pointer) to Proposed Standard

JSON Pointer does not distinguish between objects and arrays. That is not determined until the pointer is applied to an actual object instance... the pointer "/1" is valid against {"1":"a"} or ["a","b"]

On Fri, Dec 14, 2012 at 2:51 AM, Markus Lanthaler <[email-masked]> wrote:

{
  "foo": "bar",
  "1": "baz"
}

Thanks,
Markus

--
Markus Lanthaler
@markuslanthaler

---

From: James M Snell <[email-masked]>
Date: Fri, 14 Dec 2012 09:18:34 -0800

How so? Doesn't appear to be a problem in practice.

On Fri, Dec 14, 2012 at 9:17 AM, Markus Lanthaler
<[email-masked]>wrote:

> Hmm.. I think that’s quite problematic. Especially considering how JSON
> Pointer is used in JSON Patch.****
>
> ** **
>
> ** **
>
> --****
>
> Markus Lanthaler****
>
> @markuslanthaler****
>
> ** **
>
> ** **
>
> ** **
>
> *From:* James M Snell [mailto:[email-masked]]
> *Sent:* Friday, December 14, 2012 5:41 PM
> *To:* Markus Lanthaler
> *Cc:* IETF Discussion; IETF Apps Discuss
> *Subject:* Re: [apps-discuss] Last Call:
> <draft-ietf-appsawg-json-pointer-07.txt> (JSON Pointer) to Proposed Standard
> ****
>
> ** **
>
> pointer "/1" is valid against {"1":"a"} or ["a","b"]****
>
> ** **
>
> On Fri, Dec 14, 2012 at 2:51 AM, Markus Lanthaler <
> [email-masked]> wrote:****
>
> @markuslanthaler****
> https://www.ietf.org/mailman/listinfo/apps-discuss****
>
> ** **
>

---

From: "Markus Lanthaler" <[email-masked]>
Date: Fri, 14 Dec 2012 18:38:31 +0100

On Friday, December 14, 2012 6:19 PM, James M Snell wrote:

> > On Fri, Dec 14, 2012 at 9:17 AM, Markus Lanthaler wrote:
> >

Since it doesn't express the authors intent. For example, assume you have a JSON Patch document like the following:

   [
     { "op": "test", "path": "/1", "value": 68 },
     { "op": "add", "path": "/2", "value": 105 }
   ]

What would you expect it to do? I think almost everyone would say that it set the third element of an array to 105 iff the second value is 68. So you might expect to get back an array on success but what you really get back might be something like this: 

{
  "some": "value",
  "1": 68,
  "some other": "value",
  "and": "finally",
  "2": 105
}

Maybe having something like ~2 to express that a number is to be treated as an array index would solve it!?

--
Markus Lanthaler
@markuslanthaler

---

From: James M Snell <[email-masked]>
Date: Fri, 14 Dec 2012 09:42:58 -0800

The author just needs to be aware of the current state of the object being
patched. Using conditional requests mechanisms can make it more reliable.

On Fri, Dec 14, 2012 at 9:38 AM, Markus Lanthaler
<[email-masked]>wrote:

> Since it doesn't express the authors intent. For example, assume you have
> a JSON Patch document like the following:
>
>    [
> What would you expect it to do? I think almost everyone would say that it
> set the third element of an array to 105 iff the second value is 68. So you
> might expect to get back an array on success but what you really get back
> might be something like this:
>
> {
>   "some": "value",
>   "1": 68,
>   "some other": "value",
>   "and": "finally",
>   "2": 105
> }
>

---

From: Robert Sayre <[email-masked]>
Date: Sat, 15 Dec 2012 20:36:07 -0800

> Hmm.. I think that’s quite problematic. Especially considering how JSON Pointer is used in JSON Patch.

I agree--I provided the same feedback privately. It seems
straightforwardly unsound.

- Rob

---

From: James M Snell <[email-masked]>
Date: Sat, 15 Dec 2012 21:22:57 -0800

On Sat, Dec 15, 2012 at 8:36 PM, Robert Sayre <[email-masked]> wrote:

> Pointer is used in JSON Patch.
>
In practice it doesn't seem to be much of an issue.

Specifically, if I GET an existing document and get an etag with the JSON,
then make some changes and send a PATCH with If-Match, the fact that any
given pointer could point to an array or object member doesn't really
matter much.

For example:

  >  GET /the/doc HTTP/1.1

  <  HTTP/1.1 200 OK
     ETag: "my-document-tag"
     Content-Type: application/json

     {"1":"foo"}

  >  PATCH /the/doc HTTP/1.1
     If-Match: "my-document-etag"
     Content-Type: application/json-patch

     [{"op":"add","path":"/2","value":"bar"}]

Generally speaking, someone should not be using PATCH to perform a partial
modification if they don't already have some knowledge in advance what they
are modifying. The only time the apparent ambiguity becomes an issue is
when a client is blindly sending a patch to an unknown endpoint... in which
case, you get whatever you end up with.

- James

> > Subject: Re: [apps-discuss] Last Call:
> > JSON Pointer does not distinguish between objects and arrays. That is
> not determined until the pointer is applied to an actual object instance...
> the pointer "/1" is valid against {"1":"a"} or ["a","b"]
> >
> >
> >
> [email-masked]> wrote:
> >

---

From: Matthew Morley <[email-masked]>
Date: Sun, 16 Dec 2012 19:33:37 -0500

I am usually lurking and struggling to keep up with these posts. But, I
concur with James, this really is a non-issue in practice.

The JSON Pointer expresses a path down a JSON object to a specific context.
The Patch expresses a change within or to that context.
Everything about the both standards is about that end context.

If you want to confirm the type of the context before applying a patch,
this should probably be part of a test operation. I'm not sure if this is
possible at this point (?), but that is where the logic should exist.

On Sun, Dec 16, 2012 at 12:22 AM, James M Snell <[email-masked]> wrote:

>> > > [email-masked] mailing lists by 2012-12-25. Exceptionally, comments
>> may
>> > > be

-- 
Matthew P. C. Morley

---

From: James M Snell <[email-masked]>
Date: Sun, 16 Dec 2012 18:35:42 -0800

Using json-patch with my json-predicates draft allows testing for existing
value type before applying a patch operation.
On Dec 16, 2012 4:33 PM, "Matthew Morley" <[email-masked]> wrote:

>> Specifically, if I GET an existing document and get an etag with the
>> JSON, then make some changes and send a PATCH with If-Match, the fact that
>> any given pointer could point to an array or object member doesn't really
>> matter much.
>>
>> For example:
>>
>>   >  GET /the/doc HTTP/1.1
>>
>>   <  HTTP/1.1 200 OK
>>      ETag: "my-document-tag"
>> Generally speaking, someone should not be using PATCH to perform a
>> partial modification if they don't already have some knowledge in advance
>> what they are modifying. The only time the apparent ambiguity becomes an
>> issue is when a client is blindly sending a patch to an unknown endpoint...
>> in which case, you get whatever you end up with.
>>
>> - James
>>
>>
>>
>>> - Rob
>>>
>>>
>>> >
>>> > --
>>> >
>>> > Markus Lanthaler
>>> >
>>> > @markuslanthaler
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >

---

From: Robert Sayre <[email-masked]>
Date: Sun, 16 Dec 2012 20:36:19 -0800

The cost of fixing it seems low, either by changing the path syntax of
JSON pointer or changing the names of operations applied to arrays.
Array-like objects are common enough in JavaScript to make this a
worry. The other suggestions either assume a particular policy for
concurrent edits or require more machinery (test operation etc).
Wouldn't it be simpler to make the patch format more precise?

- Rob

On Sun, Dec 16, 2012 at 4:33 PM, Matthew Morley <[email-masked]> wrote:
> If you want to confirm the type of the context before applying a patch, this
> should probably be part of a test operation. I'm not sure if this is
>> given pointer could point to an array or object member doesn't really matter
>> much.
>>
>> For example:
>>
>>   >  GET /the/doc HTTP/1.1
>>
>>   <  HTTP/1.1 200 OK
>>      ETag: "my-document-tag"
>> are modifying. The only time the apparent ambiguity becomes an issue is when
>> a client is blindly sending a patch to an unknown endpoint... in which case,
>> you get whatever you end up with.
>>
>> - James
>>
>>
>>>
>>> - Rob
>>>
>>>
>>> >
>>> > --
>>> >
>>> > Markus Lanthaler
>>> >
>>> > @markuslanthaler
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >

---

From: Conal Tuohy <[email-masked]>
Date: Mon, 17 Dec 2012 14:47:53 +1000

On 17/12/12 10:33, Matthew Morley wrote:
> I am usually lurking and struggling to keep up with these posts. But, 
> I concur with James, this really is a non-issue in practice.
>
> If you want to confirm the type of the context before applying a 
> patch, this should probably be part of a test operation. I'm not sure 
> if this is possible at this point (?), but that is where the logic 
> should exist.

On the other hand, it's certainly true that this syntax has the 
potential to confuse programmers, and surely that should be avoided if 
possible? There's nothing to be gained by confusing coders. Having a 
distinct syntax for array indices and object names (as JSON itself does) 
would not be too difficult, and it would eliminate this particular 
confusion.

Does JSON Pointer have any role outside of JSON Patch? I would guess so, 
given that it's specified separately. In which case, aren't there use 
cases where one might want to refer to a value in a JSON object other 
than for purposes of patching it, without explicit knowledge of a 
previous state of the object?

In the XML world, the equivalent language XPath is used within a large 
number of other languages; XPointer, XSLT, XQuery, XForms, etc, etc. It 
would be a shame if the narrow requirements of JSON Patch were used to 
justify taking a shortcut with JSON Pointer, in a way that makes it less 
useful for other (non-patching) purposes.

-- 
Conal Tuohy
HuNI <http://huni.net.au/> Technical Coordinator 
<http://apidictor.huni.net.au/trac/wiki/ConalSpace>
Victorian eResearch Strategic Initiative 
<http://versi.edu.au/about-us/versi-team#Con>
Skype: conal.tuohy
Twitter: @conal_tuohy <https://twitter.com/conal_tuohy>
Mobile: +61-466324297 <tel:+61-466324297>

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 17 Dec 2012 16:41:24 +1100

Robert, 

This was discussed extensively in the Working Group. 

The root of the issue was that some people reflexively felt that this was necessary, but upon reflection, we decided it wasn't; although it seems "natural" to some, especially those coming from a static language background, it didn't provide any utility.

You might argue that someone who (for example) adds to "/foo/1" in the mistaken belief that it's an array, when in fact it's an object, will get surprising results. That's true, but if we were to solve this problem, that person would still need to understand the underlying semantics of "foo" to do anything useful to it -- and I'm not hearing anyone complain about that (I hope).

Put another way -- do you really think that people PATCHing something as if it's an array (when in fact it's an object) is a significant, real-world problem, given that the patch author already has to understand the semantics of the document they're patching? I don't, and the WG didn't either.

Regards,

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

---

From: Robert Sayre <[email-masked]>
Date: Mon, 17 Dec 2012 02:01:27 -0800

> This was discussed extensively in the Working Group.

Presumably every line of the document was discussed by the WG at some
point. This phase of review is wider, and this point has been raised
separately three times, so perhaps the WG should take another look.
One thing that strikes me about the arguments in favor of the status
quo is that they seem non-technical. Is there a technical case for
leaving this ambiguity in the patch format?

> The root of the issue was that some people reflexively felt that this was necessary, but upon reflection, we decided it wasn't; although it seems "natural" to some, especially those coming from a s…

I'm approaching it as an implementor in JavaScript that happens to
have spent some on the ECMAScript committee and implemented the native
JSON.parse and JSON.stringify methods for Mozilla Firefox. I think
this issue leaves open a chance for data corruption with no real
upside. I could understand leaving it be if making arrays explicit in
the patch format were complex or onerous, but I don't think anyone is
arguing that.

> You might argue that someone who (for example) adds to "/foo/1" in the mistaken belief that it's an array, when in fact it's an object, will get surprising results. That's true, but if we were to s…

The first case that can come up is editing documents that have been
refactored. It's quite common to refactor JSON documents as below when
a little extra metadata is needed for a collection:

{ "foo":[1,2,3] }

then becomes

{
  "foo":
  "bar": "baz",
  "members": [1,2,3]
}

now, an operation on /foo/1 is quite a different thing in the second
document. It's not too hard to see how a client that's been out of
contact with the server for a while could send an addition to /foo
intended for the array that's been moved down to "members". Now, there
are ways to catch this if you're willing to bloat the patch document
with other checks, or by insisting on a matching ETag. But one of the
nice things about patch formats is that you can try for more
optimistic concurrent editing. This ambiguity in the patch format
makes it needlessly more costly to detect unsound edits.

Another source of bugs from JavaScript side of things will be
"array-like" objects. These are really quite common (jQuery lists,
arguments object, etc), and authors very often don't realize they
won't be serialized as an array. To be sure, this is a bug on the
author's side, but some checks in the patch format would really help.
They'll probably become even more common as ES6 is standardizing
iterators http://wiki.ecmascript.org/doku.php?id=harmony:iterators.
Here's an example in a JS REPL using the arguments object (but keep in
mind there are many other objects out there that behave this way).

> function foo(list) { console.log(JSON.stringify(list)) }
> function bar(a,b,c) { foo(arguments) }
> bar("a", "b", "c");
{"0":"a","1":"b","2":"c"}

>
> Put another way -- do you really think

Yes, really.

> that people PATCHing something as if it's an array (when in fact it's an object) is a significant, real-world problem, given that the patch author already has to understand the semantics of the document they're patching?

I don't see that requirement in the draft, and I certainly wouldn't
bet on it being true in all cases. Wasn't one of the motivating
use-cases for this patch format CouchDB? That software operates on
arbitrary, user-defined JSON documents.

- Rob

> I don't, and the WG didn't either.
>
> Regards,
>
>

---

From: Robert Sayre <[email-masked]>
Date: Mon, 17 Dec 2012 06:19:15 -0800

> a little extra metadata is needed for a collection:

Oh drat, I missed a pair of brackets here.

I meant:

{
  "foo":
  {
    "bar": "baz",
    "members": [1,2,3]
  }
}

- Rob

---

From: James M Snell <[email-masked]>
Date: Mon, 17 Dec 2012 07:08:27 -0800

On Mon, Dec 17, 2012 at 2:01 AM, Robert Sayre <[email-masked]> wrote:

> [snip]
> >
> > You might argue that someone who (for example) adds to "/foo/1" in the
> mistaken belief that it's an array, when in fact it's an object, will get
> surprising results. That's true, but if we were to solve this problem, that
> person would still need to understand the underlying semantics of "foo" to
> do anything useful to it -- and I'm not hearing anyone complain about that
> (I hope).
>
Appreciate the concrete use case... while it has come up a few times, this
is the first actual case that's been presented. If I understand the issue
correctly, you're basically talking about a client making a blind partial
update to an arbitrarily structured JSON document whose structure may have
changed since the last time the client edited it...  In such cases, I would
argue that you get whatever you end up with.

Everyone's idea of "bloat" is different. Adding etag checking is a simple,
effective best practice for detecting concurrent document changes and is
likely a really good idea in a scenario where we're making partial
modifications to arbitrary documents. Adding in support for json-predicates
adds a bit more (not a lot really but opinions vary.. in the ruby
implementation it's only approximately 140 more lines of code, mostly
formatting) but can make it rather more reliable... For instance,

  [
    {"op": "type", "path": "/foo/1", "value": "array"},
    {"op": "add", "path": "/foo/1", "value": 1}
  ]

Again, the point is, I don't see this as a problem in practice.
Implementers that make blind edits to arbitrary docs can expect surprising
results sometimes. That's just the way it is. There are mechanisms defined
(test, json-predicates and conditional requests) that can make the edit
more reliable.

> {"0":"a","1":"b","2":"c"}
Definitely understand this case, but json-patch is defined in terms of the
basic json model and not javascript. In other words... again.. the
developer using the patch needs to be aware of the structure of the target
resource. Json-predicate provides a good approach to dealing with that by
allowing a developer to test the structure before attempting to edit.

- James

> > that people PATCHing something as if it's an array (when in fact it's an
> object) is a significant, real-world problem, given that the patch author
> already has to understand the semantics of the document they're patching?
>
> patch, this
> JSON,
> matter
> partial
> >>>>>> though that's probably not what the author intended. Is there a way
> to
> >>>>>> avoid
> >>>>>> that?
> >>>>>>
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Markus
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Markus Lanthaler
> >>>>>> @markuslanthaler
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>

---

From: Robert Sayre <[email-masked]>
Date: Mon, 17 Dec 2012 19:41:02 -0800

On Mon, Dec 17, 2012 at 7:08 AM, James M Snell <[email-masked]> wrote:
>
> Everyone's idea of "bloat" is different.

What I meant was that the predicate additions increase the size of the
protocol messages. Your example is twice as large. The check could be
more efficiently represented in the path notation or the operation
names.

> Again, the point is, I don't see this as a problem in practice. Implementers
> that make blind edits to arbitrary docs can expect surprising results
> sometimes. That's just the way it is. There are mechanisms defined (test,
> json-predicates and conditional requests) that can make the edit more
> reliable.

Well, one way of putting it would be that the patch format makes it
difficult to ensure convergence at quiescence in OT software when
there's a change in type from array to object or vice-versa:

<http://en.wikipedia.org/wiki/Operational_transformation#The_CC_model>

There's no good reason for it to be that way, is there?

- Rob

---

From: James M Snell <[email-masked]>
Date: Mon, 17 Dec 2012 19:53:48 -0800

The key advantage to the current syntax is that it's just absolutely drop
dead simple. I get what you're saying but I'd rather avoid increasing the
complexity of the syntax any more than we absolutely have to. And, to be
absolutely honest, I haven't yet seen an actual application case where it's
been an issue (that's not to say they don't exist, just haven't seen it in
practice yet). What's your suggestion for making the syntax better?

On Mon, Dec 17, 2012 at 7:41 PM, Robert Sayre <[email-masked]> wrote:

> Implementers

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 18 Dec 2012 16:12:49 +1100

If we were starting from scratch and defining JSON Pointer again I would argue for distinguishing array indices and object names in the syntax. For instance, prefix an object name with "/" and an array index with ":".

   json-pointer = *segment
   segment = "/" name  /  ":" index
   name = *( unescaped / escaped )
   unescaped = %x00-2E / %x30-39 / %x3B-7D / %x7F-10FFFF
   escaped = "~" ( "0" / "1" / "2" )
   index = "0" / %x31-39 *(%x30-39) / "-"

1. It makes parsing marginally harder: you cannot just split on "/" and unescape each segment.
2. It doesn't make much difference for selecting a value from some JSON, or for finding a spot to insert a new value.
3. It would allow you to automatically create object *or array* ancestors when setting a new value (eg adding 23 at /a:0/b:0 to {} could give {"a":[{"b":[23]}]}).
4. It might encourage better validation of pointers, but that is probably wishful thinking.

But JSON Pointer drafts have used the /{name|index} format for a year. There are a bunch of implementations. The difference is minor in most circumstances. So while I would be happy to change, I am also comfortable staying with the current pointer syntax.

> There's no good reason for it to be that way, is there?

I don't think so.
 
--
James Manger

---

From: James M Snell <[email-masked]>
Date: Mon, 17 Dec 2012 21:24:48 -0800

What I'm not clear on, however, is what significant benefit making this
kind of change would provide. Yes, the syntax can be more verbose and exact
but it's not clear that the change is worth the cost.

Robert mentioned that the addition of the json-predicates test doubled the
size of the json-patch file, and yes, I get that.. but if we're talking
about sending a two-object json-patch document to modify a JSON document
many times larger than that, it's still worth the extra handful of bytes it
takes. Sure, if we had a complex patch document consisting of large amounts
of json-patch and json-predicate objects being applied to an arbitrarily
structured document, I could understand the concern, but in that case one
would have to question the wisdom of doing a partial update in the first
place. JSON-Patch documents are best served small and simple, and the
inclusion of a json-predicate or two per instance is not going to blow the
budget on bits on the wire.

So the key question becomes: what added benefit does a more verbose pointer
syntax provide us? And is there a concrete need for that benefit that can
be demonstrated?

- James

On Mon, Dec 17, 2012 at 9:12 PM, Manger, James H <
[email-masked]> wrote:

> If we were starting from scratch and defining JSON Pointer again I would
> argue for distinguishing array indices and object names in the syntax. For
> instance, prefix an object name with "/" and an array index with ":".
>
>    json-pointer = *segment
> 2. It doesn't make much difference for selecting a value from some JSON,
> or for finding a spot to insert a new value.
> 3. It would allow you to automatically create object *or array* ancestors
> when setting a new value (eg adding 23 at /a:0/b:0 to {} could give
> {"a":[{"b":[23]}]}).
> But JSON Pointer drafts have used the /{name|index} format for a year.
> There are a bunch of implementations. The difference is minor in most
> circumstances. So while I would be happy to change, I am also comfortable
> staying with the current pointer syntax.
>
>

---

From: Matthew Morley <[email-masked]>
Date: Tue, 18 Dec 2012 20:00:40 -0500

I do not feel there is a gain from adjusting the syntax, in the role of
JSON Pointer as a stand alone specification. The addition of such a change
adds an implied checking of a list vs a collection, as part of pointer
resolution.

If you are using the pointer as a means to get a value, it makes little
difference in the fact that the value either exists at the end of that path
or it doesn't.  (Get me the value at /a/b/c/2)

If you are using the pointer as a method of identity, again it makes little
difference as only one point can presented by that pointer. (You are at
/a/b/c/2)

For me, these are the primary uses of the JSON Pointer specification.
Rarely is the underlying structure, in practice, of consequence.

Something like JSON-Schema is much better for testing the shapes of JSON
data.

However, I can see the point in such a change when paired with JSON-Patch.
But I still feel that even this is more of an attempt to overload the role
of the pointer, to make it carry additional meaning that should be
expressed in either the test or the operation keywords of that particular
specification.

My vote is to leave the specification syntax as is, and keep it simple to
produce and consume, even at the cost of not being able to infer the
structure of any given step in the pointer without the actual json object
being traversed.

-- 
Matthew P. C. Morley

On Tue, Dec 18, 2012 at 12:24 AM, James M Snell <[email-masked]> wrote:

> So the key question becomes: what added benefit does a more verbose
> pointer syntax provide us? And is there a concrete need for that benefit
> that can be demonstrated?
>
> - James
>
>