On Thu, Jun 9, 2011 at 11:38 AM, Paul Davis <[email protected]> wrote:
> On Thu, Jun 9, 2011 at 2:09 PM, Paul C. Bryan <[email protected]>
> 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
...
> 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("/").
Cheers,
Eli
