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

["Murray S. Kucherawy" <superuser@xxxxxxxxx>]

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 <pbryan@xxxxxxxx> 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
apps-discuss@xxxxxxxx
https://www.ietf.org/mailman/listinfo/apps-discuss