On Sat, 2013-01-05 at 16:19 -0800, Robert Sayre wrote:
[snip]
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.
[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.
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.
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. Our reasoning for resisting such change is legitimate.
The reason I value implementations is because they endorse the specification through tangible action. Some of their authors have participated in this forum to help improve the specification and create consensus around it. Unfortunately, you've raised objections quite late in the process, and I'm personally not persuaded that the issues you've raised warrants (likely significant) changes.
Paul