This is great stuff! It would be nice to have some more operations like "increment", "decrement", "push", "pop", "compare-and-swap", etc. I think error handling should be better addressed, possibly returning an array of "result" objects (or something similar).
Also, I don´t think one should mention idempotency of patches, since they seem to me inherently state dependent. regards, Daniel On Thu, Jun 9, 2011 at 3:38 PM, 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 > > > > 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 >
