On Sun, Jan 6, 2013 at 3:35 PM, Paul C. Bryan <pbryan@xxxxxxxx> wrote: > Thank you for the technical response. > > 1) The ambiguity around arrays makes the patch format unsuitable for common > concurrent editing algorithms. > > > Common concurrent editing algorithms should, in my opinion, use techniques > to ensure the state of the resource (relative to the edits) is known. In > HTTP, we have ETag and If-Match/If-None-Match preconditions. In JSON Patch, > we have (a rudimentary) test operation. That is sequential editing, not concurrent editing. Here are a few links to make sure we're not talking past each other: http://en.wikipedia.org/wiki/Operational_transformation#Basics The above overview section contains a two-step insert/delete process bearing an uncanny resemblance to a JSON Patch document. Here's some software that uses patch documents in this fashion: http://en.wikipedia.org/wiki/Operational_transformation#OT_software > > [snip] > > > 3) It's not possible to tell whether a JSON Pointer document is > syntactically correct in isolation. > > > There is no such thing as a JSON Pointer document. Yes, I meant JSON Pointer /reference/. This error seems tangential to the thread in general, though, which is why I didn't bother to correct myself when others raised this point. > > This issue is a problem in practice, and it's a problem in theory as well. > JSON-Patch messages aren't sufficiently self-descriptive, so they aren't > appropriate for use in a RESTful system. > > > 99% of RESTful systems I'm familiar with are based on HTTP. Where optimistic > concurrency is acceptable, HTTP preconditions seems to provide acceptable > coverage. Where more granularity or more pessimistic concurrency is > required, implementors are free to use their own mechanisms, including more > expressive predicates (as has been proposed here, with my endorsement) > and/or resource locking. These are intentionally out of scope for JSON > Patch. Fully disagree. My point is that the array ambiguity makes it hard to implement more optimistic concurrency. > > Later in this thread, you wrote: > > Ah. I meant that the WG seems to be favoring "running code" a little too > heavily in the presence of a bug. It's an old argument, and it's boring: "We > can't change it now, there are already twelve users!" > > > I don't agree that this is a bug; it lacks a feature that you and some > others have requested. The only rationale I've seen prior to my message was something about "feeling natural" and "static languages" that I admit I don't fully understand. Are there other technical arguments I've missed? I'm happy to go read up. > Our reasoning for resisting such change is > legitimate. This last assertion really isn't qualified very well. Do you have a more extensive rationale, or is a simple contradiction the extent of your argument? - Rob