incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Itaboraí <>
Subject Re: JSON Patch Internet Draft 01
Date Thu, 09 Jun 2011 19:47:57 GMT
This is great stuff!

It would be nice to have some more operations like "increment", "decrement",
"push", "pop", "compare-and-swap", etc. I think error handling should be
better addressed, possibly returning an array of "result" objects (or
something similar).

Also, I don´t think one should mention idempotency of patches, since they
seem to me inherently state dependent.


On Thu, Jun 9, 2011 at 3:38 PM, Paul Davis <>wrote:

> On Thu, Jun 9, 2011 at 2:09 PM, Paul C. Bryan <>
> wrote:
> > The second draft of the JSON Patch proposal has been published:
> >
> >
> > Feedback would be most appreciated. The mailing list for this proposal
> > is:
> >
> >
> > Paul
> >
> Paul,
> Thanks for the update. There are a few details I'm still not quite sure on.
> In the JSON Pointer RFC it states that path components SHOULD be URI
> encoded and that "/" MUST BE uri encoded but in the algorithm
> description for moving the reference pointer there's no language on
> URI-decoding the path component. Also I have no idea how this would
> play with utf-8 or other unicode representations. Perhaps just
> escaping any "/' characters would be enough here though that could get
> confusing as it'd be "\\/" in all the examples.
> This note on array mutations "It is an error condition if the addition
> would result in sparse allocation of any array elements." might read
> better as something like "It is an error condition is greater than the
> length of the array."
> The language in section 6 worries me a bit on its possible
> interpretations. I'd either opt for "behavior after an error occurs is
> undefined" or the other end of the spectrum "if a JSON diff can not be
> applied without error then it must not have any side effects".
> The interaction between JSON patch and JSON pointer confuses me a bit.
> The JSON patch doesn't mention it, but its implicitly saying that it
> must parse the path and strip a token before the JSON pointer
> algorithm is applied. For instance, the first example:
>   An example target JSON document:
>   {
>     "foo": "bar"
>   }
>   A JSON Patch document:
>   [
>     { "add": "/baz", "value": "qux" }
>   ]
>   The resulting JSON document:
>   {
>     "baz": "qux",
>     "foo": "bar"
>   }
> As I read JSON pointer, if I attempted to retrieve "/baz" from {"foo":
> "bar"} it would result in an error because "baz" does not exist in
> that JSON doc. So what JSON patch is saying is that i have to strip
> the final JSON pointer path component before retrieving that JSON
> pointer. I'm not sure if that's not a big deal, or if the JSON patch
> operations might be better suited with a third parameter that lists
> the final component so we minimize implementations of JSON pointer
> parsing?
> Other than that it all looks promising.
> HTH,
> Paul Davis

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message