On Wed, Apr 20, 2011 at 4:04 PM, Paul C. Bryan <[email protected]> wrote: > On Wed, 2011-04-20 at 15:15 -0400, Paul Davis wrote: > > Thanks for the feedback. > > >> On Wed, Apr 20, 2011 at 2:31 PM, Paul C. Bryan <[email protected]> >> wrote: >> > I just posted an informational Internet-Draft regarding a JSON media >> > type to support HTTP PATCH partial modifications—something I've desired >> > in CouchDB for a while, since this thread: >> > http://web.archiveorange.com/archive/v/pNInH33bynEnhjlOlX5f >> > >> > http://tools.ietf.org/html/draft-pbryan-json-patch-00 >> > >> > Any feedback would be appreciated. >> > >> > Paul >> > >> >> Cool work. Though I would argue against relying on JSONPath in the >> spec, because JSONPath has no spec itself. I did a fairly similar >> thing to this but instead of using paths I added operations for moving >> around the JSON object. There's code for it in a Python package [1] >> that I'll try and remember to move to github later tonight. > > > > Yes, I went back and forth on the use of JSONPath. Eventually, I settled > on using it because it does provide a well-defined format and the > prospect of reinventing it put me off. I'm currently in the process of > trying to get a stable subset of JSONPath published as an I-D as well. >
Cool. When you have a draft make sure and post a link. > >> Also, I would remove all wording about HTTP from the specification. >> Just because CouchDB might use the HTTP PATCH verb to apply JSON diffs >> doesn't mean the diff format should be aware that HTTP even exists. >> That's be like saying that unified diff's are only valid when applied >> over email or something. >> >> [1] http://pypi.python.org/pypi/jsontools/0.1 > > > I only mean HTTP and HTTP PATCH to be as informative references—I would > like there to be a patch document format for JSON that is used with HTTP > PATCH. Maybe I can lighten—but not totally eliminate—my references to > them? :-) > > Paul > > I could see mentioning them in a motivation section. On the other hand, mentioning PATCH in the error handling section seems inappropriate. Error conditions for JSON diffs should resolve around possible errors like inserting an element beyond the end of an array or at a negative offset or such things.
