incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eli Stevens (Gmail)" <>
Subject Re: JSON Patch Internet Draft 01
Date Thu, 09 Jun 2011 23:39:30 GMT
On Thu, Jun 9, 2011 at 11:38 AM, 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:
>   An example target JSON document:
>   {
>     "foo": "bar"
>   }
>   A JSON Patch document:
>   [
>     { "add": "/baz", "value": "qux" }
>   ]
>   The resulting JSON document:
>   {
>     "baz": "qux",
>     "foo": "bar"
>   }

I think that it should be possible to specify what value should be
present when removing something.  Text-based patches don't just say
"remove line 42" they also spell out what content is expected to be
there before removal.  Similarly, I think that supporting context
verification is important.  Something like the following being applied
to the resulting doc above:

    { "verify": "/foo", "value": "bar" },
    { "replace": "/baz", "value": 42, "oldvalue": "qux" }

That might warrant a rename from "value" to "newvalue" but if
"oldvalue" is optional, maybe the asymmetry between the names isn't a
big deal.

For what it's worth, I don't think that using a list of strings for
the pointer is bad at all.  Why invent a new string sub-syntax when
you can use an existing JSON structure?  Having wasted more hours of
my professional life lamenting trying to cram arbitrary user data into
the path portion of a URL than I care to admit, I can't recommend the
approach.  Spelling the separator as "," instead of / isn't that big
of a deal, esp. when for simple cases with a full JS interpreter
handy, one could use "/a/b/c".split("/").


View raw message