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

[James M Snell <[e-mail]>]

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 <
[e-mail]> 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
>    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
>