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

[James M Snell <[e-mail]>]

If I may, I would follow this up with a suggestion that a separate I-D that
provides a more complete treatment of fully-concurrent patch operations
would be helpful. JSON-Patch is largely designed around atomic and
sequential modification operations and is not, necessarily a great match
for the kind of OT-style mechanisms Robert was referencing. I don't
personally have any use cases that would require the level of concurrency
Robert is suggesting but it would be an interesting pursuit nonetheless.


On Mon, Jan 7, 2013 at 8:40 PM, Murray S. Kucherawy <[e-mail]>wrote:

> I apologize for being absent for this thread until now.  Vacation and
> medical matters interfered with me keeping current.
>
> First, with my participant hat on:
>
> I've been occasionally comparing this work to conventional UNIX "patch" to
> try to maintain a point of reference as these works developed.  As such,
> I'm swayed by the argument (which, as I recall, was part of working group
> deliberations prior to WGLC) that we have the "test" operations, so people
> generating patch documents should use them to ensure proper context before
> applying any of the operations that alter the target.  UNIX "patch"
> accomplishes this by default by surrounding the lines to be changed in the
> target with context lines that aren't changed, and so must exist precisely
> as-is before the change can be made or the change is rejected.  Consider a
> target file comprising 26 lines, each containing the next character of the
> upper-case English alphabet and a newline, but the M and the N lines are
> swapped.  A typical patch to fix this would look like so:
>
> --- x   Mon Jan  7 20:27:36 2013
> +++ y   Mon Jan  7 20:27:40 2013
> @@ -10,8 +10,8 @@
>  J
>  K
>  L
> -N
>  M
> +N
>  O
>  P
>  Q
>
> The default for UNIX "diff" is to produce three lines of context above and
> below the change to be made to ensure the change is being made in the right
> place.  One could also request no lines of context, yielding:
>
> --- x   Mon Jan  7 20:27:36 2013
> +++ y   Mon Jan  7 20:27:40 2013
> @@ -13 +12,0 @@
> -N
> @@ -14,0 +14 @@
> +N
>
> But this doesn't bother to check any context, except of course to ensure
> that the target file is at least 14 lines long.  Although the top one is
> clearly safer, both are actually legal patches.
>
> In my view, these two JSON documents present a language for referencing
> and object and changing it, and also for querying for context, just like
> the conventional UNIX diff/patch format does.  But in neither the UNIX case
> nor the proposed JSON case is the context part mandatory to use (though one
> could certainly argue it's foolish to skip doing so).  That seems fine to
> me.
>
> Then, with my co-chair hat on:
>
> Although I hear and understand Robert's position that this is an important
> thing that needs to be addressed, it is not my view after reviewing this
> thread that there's rough consensus to reopen the question.  Please note
> that this is not an "it's too late in the process to change this" position,
> but rather one that notes that the burden of supporting a change to
> something that already has rough consensus is on the person proposing the
> change, and I don't believe Robert has succeeded here.
>
> That said, I would ask the document editors to consider adding a paragraph
> or an appendix indicating this issue was considered during development of
> the work and the current format was deliberately selected, preferably with
> some supporting text.  This will ensure future readers will not interpret
> the chosen design as a bug, but rather an intentional design choice.
>
> -MSK, APPSAWG co-chair
>
> On Mon, Jan 7, 2013 at 5:33 PM, Paul C. Bryan <[e-mail]> wrote:
>
>> **
>> On Sun, 2013-01-06 at 16:01 -0800, Robert Sayre wrote:
>>
>>  This last assertion really isn't qualified very well.
>>
>>
>> It would have been better for me to state this is my opinion, based on
>> discussions that were animated from similar objections raised in the past.
>>
>> Paul
>>
>> _______________________________________________
>> apps-discuss mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>
>>
>
> _______________________________________________
> apps-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>