On Sun, Jan 6, 2013 at 8:15 PM, Robert Sayre <say...@gmail.com> wrote:
> On Sun, Jan 6, 2013 at 4:01 PM, Robert Sayre <say...@gmail.com> wrote: > > On Sun, Jan 6, 2013 at 3:35 PM, Paul C. Bryan <pbr...@anode.ca> wrote: > >> > >> > >> 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. > ... > > links to make sure we're not talking past each other: > > Actually, let me restate my point in terms of RFC5789 (HTTP PATCH). > That will make it easier to communicate. > > RFC 5789 Section 2.2 (Error Handling) defines error conditions which > correspond directly to the point at hand: 'Conflicting state' and > 'Conflicting modification'. Section 5 of the JSON Patch document > directly references RFC5789, Section 2.2. > > With that in mind, let's note that there are several normative > requirements in the JSON Patch document directed at conflicting state. > One such example is from Section 4.2 'remove'. It reads: "The target > location MUST exist for the operation to be successful.". If a server > received an HTTP JSON Patch request attempting to delete a > non-existent location, this text from RFC5789 would seem to apply: > > "Conflicting state: Can be specified with a 409 (Conflict) status > code when the request cannot be applied given the state of the > resource. For example, if the client attempted to apply a > structural modification and the structures assumed to exist did > not exist ..." > > The text above wouldn't be necessary in JSON Patch or RFC5789 if > RFC5789 required checking ETags and preconditions for all use cases > (it doesn't). The larger point is that RFC5789, and patch formats in > general, make all sorts of allowances for *non-conflicting* concurrent > edits to a common ancestor. The problem with leaving this JSON Pointer > array ambiguity in the draft is that patch messages which should > trigger '409 Conflict' errors can be mistakenly and 'successfully' (in > the HTTP sense) applied to a different structure than intended. > > In summary, the JSON Patch draft allows patch documents to be > formulated that make it impossible to correctly implement RFC5789, a > normative reference. > > Here are the questions the IESG focuses on during review: > "Reviews should focus on these questions: 'Is this document a > reasonable basis on which to build the salient part of the Internet > infrastructure? If not, what changes would make it so?'" > > For JSON Patch, the answer to the first question is 'no', because of a > deficiency in JSON Pointer. The change needed to make these documents > acceptable as part of the Internet infrastructure is to make Arrays > explicit in JSON Pointer syntax. > > - Rob > For me the deficiency is not in the pointer, but patch format being generated. One approach is to push that *one* test, structure conformity, into the pointer syntax. Another is via the type operation. If a vague patch is generated, vague results are to be expected. Testing for *just* the structure does not really create a verbose patch either. Which is why I am not overly in favor of a syntax specific to arrays, with this argument. For example, if you are replacing a key in a object, the json-pointer to get there, *and* the value would be required to ensure it is not vague. Setting /a/b/c to 6 when it was 4, and applying that patch without such tests to a document where /a/b/c is 13, is also vague. Without tests, the patch format is optimistic at best, there is no escaping this fact. Changing the spec for the json-pointer syntax to address vagueness in json-patch specification seems wrong to me. If json-pointer is not well suited, because of the desire for a descriptive path which includes structure and value, perhaps a different specification is need. One that provides both path, structure, and value confirmation in the pointer string. Though at that point is more of a query path, so something like JsonPath (http://goessner.net/articles/JsonPath/)? I prefer the test/type operations and the json-pointer specification, with optimistic patches. -- Matthew P. C. Morley
