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 <jsr@xxxxxxxxx> 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)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.-jOn Mon, Jan 7, 2013 at 10:26 PM, Matthew Morley <matt@xxxxxxxx> wrote:
On Mon, Jan 7, 2013 at 5:39 PM, Conal Tuohy <conal.tuohy@xxxxxxxxxxxx> wrote:
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.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.
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
apps-discuss@xxxxxxxx
https://www.ietf.org/mailman/listinfo/apps-discuss
_______________________________________________
apps-discuss mailing list
apps-discuss@xxxxxxxx
https://www.ietf.org/mailman/listinfo/apps-discuss