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

[Jared Rosoff <[e-mail]>]

I'm definitely not trying to expand the scope beyond the current draft.
More trying to share some experience with an existing implementation of
something similar.

A few comments on path syntax based on this experience.

1) It seems like some of the examples raised on this thread conflate JSON
documents with Javascript objects. According to the json spec, an object
always starts with an "{" and ends with a "}". Therefore, while the json
path "/1" could refer to elements in { "1": "a" } and [1,2], the latter is
not a correct JSON object.

2) Should a JSON pointer be able to refer to the "whole document"? In the
spec, it says that the path "" would refer to the whole JSON document. I
don't think this should be possible. If you want to replace the entire
document, you should be using an HTTP PUT to replace the content, rather
than a patch. Eliminating the ability to refer to the whole document would
also release some ambiguity in certain cases.

For example, earlier it was pointed out that if i have this document

{ "a": 1 }

And then apply this patch

{ op: "add", path: "", value: [1,2,3] }

then it would result in the document after patch being

[1,2,3]

however, this is not a valid json document as it is not enclosed by { }.

Instead, I think that the empty path should refer to the element of the
document named with an empty string.

So with { a: 1 }, and the op { op: "add", path: "", value: [1,2,3] }
would result in this document:

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

This also means that the leading slash is somewhat superfluous and could be
omitted from the syntax (since the paths "", and "/" would both resolve to
the "" named element of the document. This makes parsing paths easier as
well, since you can just split the path on the "/" and take the count of
parts to figure out how deep you're going.

Given { a: 1, "": [1,2,3] }, i would refer to the 2nd array element with
the path "/2". When parsing this i'd split on "/", which gives me two
tokens, the empty string (on the left of hte /) and the number 2 (on the
right of the /).

-j

On Tue, Jan 8, 2013 at 8:19 AM, Robert Sayre <[e-mail]> wrote:

> Hi Jared,
>
> Earlier in the thread, I actually directly asked whether software that
> operates on arbitrary JSON was in scope for this WG (my example was
> CouchDB), after having suggested either changing the path syntax or
> renaming the array operations.[0]
>
> The editors didn't respond, except with process points or simple
> contradictions without rationale. My conclusion is that software such
> as MongoDB must be out of scope here. To their credit, the editors did
> point out that anyone is free to try again, and I plan to do just
> that. There's no reason to hold up this WG, since they seem to be
> burnt out.
>
> - Rob
>
> [0]
> http://www.ietf.org/mail-archive/web/apps-discuss/current/msg08552.html
>
>
> On Tue, Jan 8, 2013 at 12:26 AM, Jared Rosoff <[e-mail]> wrote:
> > hi team, i'm new to the discussion here, but wanted to jump in. i work on
> > mongodb, a json database, and i wanted to share how we deal with these
> > issues.
> >
> > mongodb uses almost the same notation for pointers ("a.b.c" instead of
> > "/a/b/c"). We also index arrays in the same way as json pointer ( "a.0"
> > refers to the 0th element of the array called "a"). and this works fine
> in
> > practice. (ref:
> http://docs.mongodb.org/manual/core/document/#dot-notation)
> >
> > our update syntax is different tho. the verbs in mongodb updates for json
> > documents are more specific:
> >
> > set / unset / rename (operations on fields)
> > inc (increment integer values)
> > push / pop / pull (operations on arrays)
> > addToSet / removeFromSet (operations on arrays)
> >
> > (ref http://docs.mongodb.org/manual/reference/operators/#update)
> >
> > since update operations are more specific and type dependent, it's easy
> to
> > throw an error if an unexpected type is encountered (e.g. try to push
> onto a
> > field that has a non-array value) and to act smartly on empty fields ( if
> > path to push is empty, we assume it should be an array, create it, and
> then
> > push the value onto it).
> >
> > i concur the the pointer syntax is fine and ambiguity comes from the
> > definition of operators in json patch.
> >
> > -j
> >
> >
> > On Mon, Jan 7, 2013 at 10:26 PM, Matthew Morley <[e-mail]> wrote:
> >>
> >> On Mon, Jan 7, 2013 at 5:39 PM, Conal Tuohy <[e-mail]>
> >> wrote:
> >>>
> >>> On 07/01/13 13:23, Matthew Morley wrote:
> >>>
> >>>
> >>> For me the deficiency is not in the pointer, but patch format being
> >>> generated.
> >>>
> >>> One approach is to push that *one* test, structure conformity, into the
> >>> pointer syntax. Another is via the type operation.
> >>>
> >>> If a vague patch is generated, vague results are to be expected.
> >>>
> >>> It seems to me, on the contrary, that the deficiency is in the pointer
> >>> syntax, and I think it would be a mistake to try to work around that
> >>> deficiency in JSON Patch. Because aren't there other things which one
> might
> >>> do with JSON Pointer than use it with JSON Patch? There's been mention
> of
> >>> having it registered as a URI fragment identifier syntax for JSON for
> >>> example. JSON Pointers could then end up all over the place, outside of
> >>> patches. IMHO JSON Pointer needs to be taken seriously as a technology
> in
> >>> its own right.
> >>
> >>
> >> Couldn't agree more about it being taken seriously in its own right. :)
> >>
> >> JSON Pointer for me exists outside of JSON Patch, always has and will do
> >> the way we think about structures. As it represents both a resolution
> path
> >> and an identity string (both ends of the path concept). I see value
> from the
> >> identity view, in describing a location that is aware of being inside an
> >> array.
> >>
> >> But JSON Pointer should not be changed just because of issues with JSON
> >> Patch, especially when JSON Patch is attempting to address those issues
> with
> >> other mechanisms within the specification. That is all I was trying to
> >> express. The syntax change should be for other reasons, if it is going
> to be
> >> made.
> >>
> >> My personal experience (for what its worth): In the past I've tried a
> >> number of syntaxes like JSON Pointer. Mostly a.b.c.0 and even a.b.c:0 at
> >> times to address the same issues suggested here. Though my experiences
> >> pushed me towards a single syntax using a.b.c.0, and thus my support for
> >> /a/b/c/0 over /a/b/c:0.
> >>
> >> The system at first used the . or : syntax, combined with dynamic
> tokens,
> >> being pointers themselves, to resolve other pointers. So it was not
> >> reasonable to know ahead of time if an end point was an array or an
> object.
> >> "a.b.c.{d.e.f}" could end up in an array or in an object, depending on
> the
> >> value at d.e.f at the time of resolution. Especially with many layers of
> >> tokens to resolve, and changing data structures.
> >>
> >> I found in practice, it didn't really matter, so the choice of . or :
> was
> >> phased out. At the end of the day the two syntaxes point to mutually
> >> exclusive points within the data, so that `meta data` about the
> structure
> >> was removed from the syntax we used. It didn't add value, even if it
> added
> >> clarity at times. We also had functions at the end of paths, but that
> goes
> >> beyond the JSON focus of the JSON Pointer goals, so those points are not
> >> relevant here.
> >>
> >> This discussion thread seems to be getting overly complicated, but JSON
> >> Pointer changes should come from the JSON Pointer view point and that
> >> specifications goals, not from short comings in JSON Patch.
> >>
> >> --
> >> Matthew P. C. Morley
> >> _______________________________________________
> >> apps-discuss mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/apps-discuss
> >>
> >
> >
> > _______________________________________________
> > apps-discuss mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/apps-discuss
> >
>