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

["Murray S. Kucherawy" <[e-mail]>]

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
>
>