Re: [apps-discuss] Last Call: <draft-ietf-appsawg-json-pointer-07.txt> (JSON Pointer) to Proposed Standard

["Paul C. Bryan" <[e-mail]>]

> 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