Per JSON specification, emphasis mine:
“An object is an unordered collection of zero or more name/value pairs…”
Any ordering difference the xdelta approach would catch would therefore
be spurious.
Paul
On Fri, 2011-06-10 at 14:06 -0400, Dave Bender wrote:
> This may be a stupid question, but how does the RFC account for the order in
> which JSON map elements appear? Are these two JSON docs considered
> equivalent:
>
> A: {"a":1,"b":2}
>
> B: {"b":2,"a":1}
>
> The xdelta approach would catch a difference in ordering whereas the RFC
> version would not.
>
>
> On Fri, Jun 10, 2011 at 1:45 PM, Paul C. Bryan
> <[email protected]>wrote:
>
> > On Thu, 2011-06-09 at 18:03 -0700, Jens Alfke wrote:
> >
> > > To play devil’s advocate: Is this format really necessary? From the
> > draft:
> > >
> > > > The HTTP PATCH [RFC5789] specification extends HTTP with a new
> > method
> > > > to perform partial modifications to resources. A JSON-based patch
> > > > document type is required to modify JSON documents using this
> > method.
> > >
> > > That’s not strictly true. A generic delta format such as xdelta3 or
> > zdelta can be used to patch any type of resource at all (and frequently is,
> > in apps like software updaters.)
> > >
> > > I can see that an advantage of JSON Patch is that, since it describes
> > structural changes rather than byte-level changes, it works even if the
> > physical representation of the JSON changes (i.e. modifications to
> > whitespace or Unicode character encoding.)
> >
> > As you point-out the challenge in using these generic formats is the
> > requirement of a byte-identical document representation. This implies
> > that the document either be stored in this serialized format, or there
> > is some normalization scheme that ensures that the document is always
> > formatted consistently before taking a patch.
> >
> >
> > > I’m just unsure whether that’s a significant enough advantage to outweigh
> > the drawbacks, including:
> >
> > I expect in some cases, it would not. In our application, we can't make
> > assumptions of the serialized expression of a JSON document, and hence
> > such a format is justifiable.
> >
> >
> > > - Much more verbose than xdelta3 or zdelta
> > > - More CPU-expensive to patch
> > > - Requires new software to generate and apply patches, rather than using
> > existing delta libraries
> > > - Has no error checking, so version mismatches could result in uncaught
> > document corruption
> >
> > Are HTTP conditions not sufficient to resolve this?
> >
> >
> > > —Jens
> >
> >
> >
