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

Re: [json] JSON Pointer Internet-Draft 01

Expand Messages
  • 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 1 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 2 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.