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

Re: JSON Patch Internet-Draft 04

Expand Messages
  • alexandre_morgaut
    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
    Message 1 of 5 , Dec 5, 2011
    • 0 Attachment
      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/

      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

      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 ;-)

      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")





      --- In json@yahoogroups.com, "Paul C. Bryan" <paul.bryan@...> wrote:
      >
      > I quickly submitted another JSON Patch Internet-Draft, now posted here:
      >
      > http://tools.ietf.org/html/draft-pbryan-json-patch-04
      >
      > It now provides a usage example for each operation, fixes a few overt
      > typographical errors and cleans up further ambiguous phrasing.
      >
      > Your review and feedback would be appreciated.
      >
      > Paul
      >
      >
      > [Non-text portions of this message have been removed]
      >
    • 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 2 of 5 , Dec 5, 2011
      • 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 3 of 5 , Dec 5, 2011
        • 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 4 of 5 , Dec 5, 2011
          • 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.