incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: JSON Patch Internet Draft 01
Date Thu, 09 Jun 2011 18:38:34 GMT
On Thu, Jun 9, 2011 at 2:09 PM, Paul C. Bryan <paul.bryan@forgerock.com> wrote:
> The second draft of the JSON Patch proposal has been published:
> http://tools.ietf.org/html/draft-pbryan-json-patch-01
>
> Feedback would be most appreciated. The mailing list for this proposal
> is:
> https://groups.google.com/group/json-patch
>
> 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

Mime
View raw message