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

JSON Pointer Internet-Draft 01

Expand Messages
  • Paul C. Bryan
    I ve posted the second draft of the JSON Pointer Internet-Draft to the IETF: http://tools.ietf.org/html/draft-pbryan-zyp-json-pointer-01 It should address all
    Message 1 of 3 , Oct 20, 2011
    • 0 Attachment
      I've posted the second draft of the JSON Pointer Internet-Draft to the
      IETF:

      http://tools.ietf.org/html/draft-pbryan-zyp-json-pointer-01

      It should address all of the outstanding issues that have been raised to
      date. Your feedback is welcome.

      Paul


      [Non-text portions of this message have been removed]
    • John Cowan
      ... Examples would be good. You also need to explain how, if at all, non-ASCII characters are encoded. -- Deshil Holles eamus. Deshil Holles eamus. Deshil
      Message 2 of 3 , Oct 21, 2011
      • 0 Attachment
        Paul C. Bryan scripsit:

        > I've posted the second draft of the JSON Pointer Internet-Draft to the
        > IETF:
        >
        > http://tools.ietf.org/html/draft-pbryan-zyp-json-pointer-01

        Examples would be good. You also need to explain how, if at all,
        non-ASCII characters are encoded.

        --
        Deshil Holles eamus. Deshil Holles eamus. Deshil Holles eamus.
        Send us, bright one, light one, Horhorn, quickening, and wombfruit. (3x)
        Hoopsa, boyaboy, hoopsa! Hoopsa, boyaboy, hoopsa! Hoopsa, boyaboy, hoopsa!
        --Joyce, Ulysses, "Oxen of the Sun" cowan@...
      • Stephan Beal
        ... i don t know if this would be useful in the larger context of your RFC, but rather than reserving a specific path character (since library-level code
        Message 3 of 3 , Oct 21, 2011
        • 0 Attachment
          On Fri, Oct 21, 2011 at 7:47 AM, Paul C. Bryan <paul.bryan@...>wrote:

          > **
          >
          > I've posted the second draft of the JSON Pointer Internet-Draft to the
          > IETF:
          >
          > http://tools.ietf.org/html/draft-pbryan-zyp-json-pointer-01
          >
          > It should address all of the outstanding issues that have been raised to
          > date. Your feedback is welcome.
          >

          i don't know if this would be useful in the larger context of your RFC, but
          rather than reserving a specific path character (since library-level code
          cannot expect arbitrary JSON to conform to one), in my code where i use
          "path-like strings" to search for JSON data i instead require that the
          caller specify the separator character (to avoid awkward encoding issues).
          So, instead of a path like "foo/bar/baz", i require "XfooXbarXbaz", where X
          is any character guaranteed (by the client, not the library!) to not appear
          in any key name in the path. That X is then used as the separator for the
          search string. This approach does not address absolute vs. relative paths,
          however, and assumes that all searches are relative to an object provided by
          the client.


          --
          ----- stephan beal
          http://wanderinghorse.net/home/stephan/


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