Loading ...
Sorry, an error occurred while loading the content.

1636Re: [json] JSON Patch

Expand Messages
  • Paul C. Bryan
    Apr 25, 2011
    • 0 Attachment
      On Sun, 2011-04-24 at 18:37 -0600, Kris Zyp wrote (in response to an
      email I sent him before I posted in this mailing list):

      > Paul,
      > This looks good, I'm glad you are working on this. A few comments:
      > * There are few things that seem overly verbose. To update a property
      > do you really need to a remove and add? It seems like the most common
      > use case would be to update a set of properties on an object. Wouldn't
      > it be preferable to do this in a more compact form? Being able to
      > provide a set of properties in an update object seems like it would be
      > a more efficient patch.

      Point taken. In an iteration prior to publishing draft 00, I actually
      had a "replace" op. It didn't take an array replacements; I was still
      relying on each node to be identified by a path (so multiple replace
      operations). It sounds like you'd like to have an array of
      property-modifications; something like a splice for objects. Am I right?

      > * It would seem that it would be nice to be able to insert/splice
      > elements in and out of arrays, so the entire arrays (or all indexes
      > after a splice) wouldn't have to be changed.

      Remove/add will do this too, but I presume the issue is the amount of
      verbosity involved?

      > * In JSON Schema we have abandoned using JSONPath. JSONPath really
      > doesn't have that signficant of adoption, and using URL friendly slash
      > delimiting and URL encoding works better within URLs and within JSON
      > strings (so you don't have to embedded quoting). See
      > http://tech.groups.yahoo.com/group/json/message/1473?threaded=1 for
      > more discussion on the subject.
      > (if you want this discussed on the JSON ML, feel free to switch over
      > there).

      Okay. I definitely see RESTful advantages to using fragment identifiers
      for sub-resource addressing. And this isn't the first pushback to using
      JSONPath I've received. Would you consider splitting fragment
      identifiers out of JSON Schema into a separate, short I-D that we can
      both reference?


      [Non-text portions of this message have been removed]
    • Show all 3 messages in this topic