incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Barnes <mrtr...@gmail.com>
Subject Re: JSON Patch Internet Draft 01
Date Fri, 10 Jun 2011 00:07:51 GMT
On path components, I wonder why an inline delimiter was chosen?

Would it be sensible to use an array instead?
Document:
{
   "a": {
     "a1":"foo",
     "a2":"foo2"
   },
   "b": "notappearinginthisfilm"
   "c": [0,1,2,4,5]
}
Patch:
[
   { "replace": ["a","a2"], "value":"bar2" },
   { "remove":  ["b"] },
   { "add": ["c", 3], "value":3 }
]

This way, there is no need to discuss string encoding or escape delimiters.

-Patrick


On 10/06/2011 4:38 AM, Paul Davis wrote:
> 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