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

Re: [json] Re: JSON Patch Internet-Draft 04

Expand Messages
  • Paul C. Bryan
    Thanks for the feedback. My comments inline: ... The first draft of JSON Patch actually used JSON Path. Since JSON Path was not standardized, I had to choose
    Message 1 of 5 , Dec 5, 2011
    View Source
    • 0 Attachment
      Thanks for the feedback. My comments inline:

      On Mon, 2011-12-05 at 09:15 +0000, alexandre_morgaut wrote:

      >
      >
      > Interesting proposal, it could be useful, but it still need some
      > work ;-)
      >
      > I'm not sure if it's best using pure path / url syntax to find the
      > target element or the JavaScript dot notation. As JSON means
      > JavaScript Object Notation, maybe JSON Patch could use the JSON Path
      > proposal (https://developer.mozilla.org/en/JSON/JSONPath) for which we
      > can already find some implementations:
      > - http://code.google.com/p/jsonpath/downloads/list
      > - http://search.cpan.org/~tobyink/JSON-Path-0.101/lib/JSON/Path.pm
      > -
      > http://rest-assured.googlecode.com/svn/tags/1.4.5/apidocs/com/jayway/restassured/path/json/JsonPath.html
      > - http://www.sitepen.com/blog/2008/03/17/jsonpath-support/

      The first draft of JSON Patch actually used JSON Path. Since JSON Path
      was not standardized, I had to choose to try to standardize JSON Path or
      do something else. For other reasons, we also needed a syntax that would
      be very easy to express in a URI fragment identifier. JSON Schema
      developed a simple syntax, which was very straightforward to implement—
      much simpler even if you only kept dot and bracket notation and dumped
      the rest. This was spun-off into the JSON Pointer specification.


      > I think it would be really more readable when you target Array indexes
      >
      > in your example
      > {
      > { "add": "/foo/1", "value": "qux" }
      > }
      > is more readable like this for many languages
      > {
      > { "add": "foo[1]", "value": "qux" }
      > }
      > (even those using round brackets)
      >
      > Maybe JSON Path does a bit too much, but at least array slices are
      > better handled
      >
      > About the operations, I think more informations may be required.
      >
      > Are JSON Patch services meant to support cross-typed operations? Which
      > behavior should we expect?
      > -> sure that saying no-support is easier

      Not sure what you mean by cross-typed operations. Can you replace a
      number with a string or object? Yes.


      > When a path is not applicable to a JSON document, should the
      > implementation try to build the missing part of the structure?
      > -> saying "no" would surely be easier, but some may be frustrated ;-)

      The latest text in draft 04 attempts to address this question and
      results in the answer being no: "The location must reference one of: the
      root of the target document, a member to add to an existing object, or
      an element to add to an existing array."


      > What if there is a scalar value at some point of the path in the
      > targeted JSON document? Should it be overridden?
      > -> an error in the current state, but if the previous point is
      > supported... it might support a media type parameter (ex:
      > "application/json-patch; override=true")

      No, by the text I quoted above, it cannot be overridden.

      Paul



      [Non-text portions of this message have been removed]
    • alexandre_morgaut
      ... I think JSONPath is kind of a de facto standard. It was chosen by ebay to create its new SQL variant ( http://ql.io/examples ) I like JSON Schema but I m
      Message 2 of 5 , Dec 5, 2011
      View Source
      • 0 Attachment
        > The first draft of JSON Patch actually used JSON Path. Since JSON Path
        > was not standardized, I had to choose to try to standardize JSON Path or
        > do something else. For other reasons, we also needed a syntax that would
        > be very easy to express in a URI fragment identifier. JSON Schema
        > developed a simple syntax, which was very straightforward to implementâ€"
        > much simpler even if you only kept dot and bracket notation and dumped
        > the rest. This was spun-off into the JSON Pointer specification.

        I think JSONPath is kind of a de facto standard. It was chosen by ebay to create its new SQL variant ( http://ql.io/examples )

        I like JSON Schema but I'm not fan of this JSON Pointer draft. The JSON Path or Pointer reference something inside the representation (HTTP Body). So yes, it could be inserted with benefits in the fragment part of the URL as it is proposed for plain text (RFC 5147) or W3C Media fragments.

        Fragments are always URL encoded either if they look as a URL like path or a JavaScript like path... I agree it'd be great to have the author propose a draft to the IETF


        > Not sure what you mean by cross-typed operations. Can you replace a
        > number with a string or object? Yes.

        I meant something like a "add" of a number to a string

        Regards,
        Alexandre
      • Paul C. Bryan
        ... No, this specification does not support mathematical, logical or string operations. Paul [Non-text portions of this message have been removed]
        Message 3 of 5 , Dec 5, 2011
        View Source
        • 0 Attachment
          On Mon, 2011-12-05 at 17:56 +0000, alexandre_morgaut wrote:


          > > The first draft of JSON Patch actually used JSON Path. Since JSON
          > Path
          > > was not standardized, I had to choose to try to standardize JSON
          > Path or
          > > do something else. For other reasons, we also needed a syntax that
          > would
          > > be very easy to express in a URI fragment identifier. JSON Schema
          > > developed a simple syntax, which was very straightforward to
          > implementâ€"
          > > much simpler even if you only kept dot and bracket notation and
          > dumped
          > > the rest. This was spun-off into the JSON Pointer specification.
          >
          > I think JSONPath is kind of a de facto standard. It was chosen by ebay
          > to create its new SQL variant ( http://ql.io/examples )
          >
          > I like JSON Schema but I'm not fan of this JSON Pointer draft. The
          > JSON Path or Pointer reference something inside the representation
          > (HTTP Body). So yes, it could be inserted with benefits in the
          > fragment part of the URL as it is proposed for plain text (RFC 5147)
          > or W3C Media fragments.
          >
          > Fragments are always URL encoded either if they look as a URL like
          > path or a JavaScript like path... I agree it'd be great to have the
          > author propose a draft to the IETF
          >
          > > Not sure what you mean by cross-typed operations. Can you replace a
          > > number with a string or object? Yes.
          >
          > I meant something like a "add" of a number to a string


          No, this specification does not support mathematical, logical or string
          operations.

          Paul



          [Non-text portions of this message have been removed]
        Your message has been successfully submitted and would be delivered to recipients shortly.