Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of mrtrick@gmail.com designates
 209.85.210.52 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        b=QzdjPgqK+jGGjD4hIC6NEXfPOvIHaO70S3MAIP7mvyWH1mW7Zo1RStOTEsALQWq+xW
         zPD0Nx9bAnmGkoMz02uNd99+2mPdJKsnNqmiT86JD2qIM9qRWm6QgGe55juM0aHteMOn
         pX9fLSXSbNkvUtWlPvhxhCvmkvH5lHCRlewbI=
Message-ID: <4DF16057.2060405@gmail.com>
Date: Fri, 10 Jun 2011 10:07:51 +1000
From: Patrick Barnes <mrtrick@gmail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10
MIME-Version: 1.0
To: user@couchdb.apache.org
Subject: Re: JSON Patch Internet Draft 01
References: <1307642964.1706.84.camel@dynamo>
 <BANLkTimzR4JKJ6Jf7fEdRm2O2ZSVpor4Sw@mail.gmail.com>
In-Reply-To: <BANLkTimzR4JKJ6Jf7fEdRm2O2ZSVpor4Sw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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
>