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

[Jared Rosoff <[e-mail]>]

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
>
>