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

[Matthew Morley <[e-mail]>]

On Sun, Jan 6, 2013 at 8:15 PM, Robert Sayre <[e-mail]> wrote:

> On Sun, Jan 6, 2013 at 4:01 PM, Robert Sayre <[e-mail]> wrote:
> > On Sun, Jan 6, 2013 at 3:35 PM, Paul C. Bryan <[e-mail]> 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