1636Re: [json] JSON Patch
- Apr 25, 2011On Sun, 2011-04-24 at 18:37 -0600, Kris Zyp wrote (in response to an
email I sent him before I posted in this mailing list):
> Paul,Point taken. In an iteration prior to publishing draft 00, I actually
> This looks good, I'm glad you are working on this. A few comments:
> * There are few things that seem overly verbose. To update a property
> do you really need to a remove and add? It seems like the most common
> use case would be to update a set of properties on an object. Wouldn't
> it be preferable to do this in a more compact form? Being able to
> provide a set of properties in an update object seems like it would be
> a more efficient patch.
had a "replace" op. It didn't take an array replacements; I was still
relying on each node to be identified by a path (so multiple replace
operations). It sounds like you'd like to have an array of
property-modifications; something like a splice for objects. Am I right?
> * It would seem that it would be nice to be able to insert/spliceRemove/add will do this too, but I presume the issue is the amount of
> elements in and out of arrays, so the entire arrays (or all indexes
> after a splice) wouldn't have to be changed.
> * In JSON Schema we have abandoned using JSONPath. JSONPath reallyOkay. I definitely see RESTful advantages to using fragment identifiers
> doesn't have that signficant of adoption, and using URL friendly slash
> delimiting and URL encoding works better within URLs and within JSON
> strings (so you don't have to embedded quoting). See
> http://tech.groups.yahoo.com/group/json/message/1473?threaded=1 for
> more discussion on the subject.
> (if you want this discussed on the JSON ML, feel free to switch over
for sub-resource addressing. And this isn't the first pushback to using
JSONPath I've received. Would you consider splitting fragment
identifiers out of JSON Schema into a separate, short I-D that we can
[Non-text portions of this message have been removed]
- << Previous post in topic Next post in topic >>