incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul C. Bryan" <paul.br...@forgerock.com>
Subject Re: JSON Patch Internet Draft 01
Date Thu, 09 Jun 2011 21:30:44 GMT
Hi Paul:

Thanks for your feedback. My comments inline:

On Thu, 2011-06-09 at 14:38 -0400, Paul Davis wrote:


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


Okay, I think I'll write-up process for encoding and decoding so as to
clarify. In a nutshell, to decode, break into tokens using "/"
separator, then URL-decode each fragment. Make sense?


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


Okay.


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


Agreed. I should have stated the latter. Will incorporate into the next
draft.


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


So, draft 00 contained an "element" property, which named the object
property or array element to add, allowing the path to reference the
parent—which would have worked with JSON Pointer. More than one person
suggested that this is too verbose and would ideally be in the pointer
itself, but—as you have noted—that spec causes "/baz" to be an error
condition according to JSON Pointer, which in this case is clearly not
the intent.

We could solve this in JSON Patch or JSON Pointer. I'm inclined to fix
JSON Pointer somehow to allow for this, as I expect JSON Patch will not
be the only example of a use where you're naming a new node to be
created. Any thoughts?

Again, thanks for the great feedback.

Paul


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