Subject: [apps-discuss] JSON Patch: jsondiff and syntax

From: Martin Algesten <[email-masked]>
Date: Sun, 11 Dec 2011 04:05:42 +0100

(Sorry Paul C. Bryan, I'm stalking you from list to list. ;)

This is in reference to a discussion from a couple of days back 
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03884.html

Parallel to Paul's work I've dreamt up another JSON patch syntax and implemented a diff/patch tool here:

https://github.com/algesten/jsondiff#readme

I don't agree that the verbosity of the JSON Patch RFC (http://tools.ietf.org/html/draft-pbryan-json-patch-04) is okay.

I believe one of the big reasons that JSON has gained such popularity over say XML, is the simplicity of it. The simplicity is gained by a loss of semantics or perhaps better call it "inferred" semantics. Such inference are even more obvious in other terse data exchange formats such as YAML.

JSON Patch goes against this by having very explicit verbs "add", "replace", "move" etc. I don't buy the argument that using gzip transfer encoding solves this. XML compresses amazingly well, but I rather see that as an argument that something is wrong in the format to start off with.

I also think about things like "diff -u" where the '+/-' becomes second nature and the patches are very readable. Currently a JSON Patch file is an instruction list of mutations - almost like a programming language, which for me is different to a diff. But then I'm clearly biased :)

Cheers,
Martin

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sun, 11 Dec 2011 15:03:05 -0800

FWIW, discussion of which format is best for a diff should really be based
on what is being compared (a file or an abstract memory structure?) and what
is expected to process the diff.

For example, JSOP has a diff format

  http://wiki.apache.org/jackrabbit/Jsop#Draft_Implementations:_JSOP-Diff

that should be evaluated based on comparing JCR repository trees and an
understanding that the main processor is going to be a server-side patch
implementation.  Given that context, our JSON represents a state of the
JCR repository: the actual diff format does not need to be JSON because
it won't be processed by a browser (only generated by XHR).

I happen to agree that choosing any verbose diff format is a non-starter,
even if we assume compression, though I have a hard time evaluating a
JSON diff proposal without a more concrete notion of what it is intended
to do and why anyone would want to use it.

....Roy

On Dec 10, 2011, at 7:05 PM, Martin Algesten wrote:

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Julian Reschke <[email-masked]>
Date: Mon, 12 Dec 2011 10:25:30 +0100

On 2011-12-12 00:03, Roy T. Fielding wrote:
> ...

I think the question here is whether Javascript is used to generate (1) 
and to process (2) the format.

For (1), it should work with XHR. JSON-Patch just is a 
JSON-serialization of a JavaScript object. The author won't need to 
write a serializer. In JSOP's diff format, the author will have to 
combine custom elements with serialized Javascript objects. As such, the 
JSON parts of the diff format shouldn't make assumptions about 
Javascript that may not be true, such as member ordering (right now it 
does sort of).

For (2), the question of what parses the format is much more 
interesting. Sure, it won't be a browser. But with JSON Patch, it can be 
an off-the-shelf JSON library (such as Jackson).

Finally, two general points:

1) I'm not sure why verbosity is a problem. If it is, we can always 
Transfer/Content-encode gzip. For readability, we could switch from 
names like "add" to symbols like "+".

2) Compact formats can be a success; see Relax NG Compact Notation. I 
think the lesson to learn here is that there should be a 1-1 mapping 
between the compact notation and the verbose notation. That's currently 
not the case for JSOP's diff format, and I believe that's a problem.

Best regards, Julian