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

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

Fortunately the JSON-Patch syntax is designed such that it is possible to
extend the range of defined operations without breaking basic structure...
much as I have done with the json-predicates draft. You would need to
define a new media type to associate with the extensions but that's not
difficult.

Consider something along the lines of.. application/json-patch-ext...

[
  {"op": "unset", "path": "/a/b"},
  {"op": "inc", "path": "/a/c"},
  {"op": "push", "path": "/a/d", "value": 1}
]

- James



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