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

[Robert Sayre <[e-mail]>]

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