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

1476Re: [json] Format & interpretation of URL fragments for JSON resources

Expand Messages
  • Jacob Davies
    Feb 27, 2010
    • 0 Attachment
      Thanks for the pointer to the discussion, that's what I was looking
      for. I guess I should also join the restful-json list.

      I don't think this is the end of the world one way or another,
      obviously! I think interoperability and consensus are more important
      than absolutely strict compliance. I guess my question was, "Is there
      a consensus?", and if there isn't a strong consensus, to raise a
      couple of points about the dot-delimited format and see what people

      On resource identification, I think that's a reasonable reading of
      that section, but I'm not sure it was intended to mean that fragment
      identifiers should not follow the same rule. For instance, this

      "For consistency, percent-encoded octets in the ranges of ALPHA
      (%41-%5A and %61-%7A), DIGIT (%30-%39), hyphen (%2D), period (%2E),
      underscore (%5F), or tilde (%7E) should not be created by URI

      isn't talking about resources versus fragments, but just about URIs in general.

      The other problem, which is minor but makes for a more complex
      explanation of the format, is that the description of keys as
      URI-encoded isn't quite right. URI-encoding does not involve
      replacement of dots in the original string with %2E. So you have to
      say something like "URI-encoding with the additional replacement of
      dots with %2E".

      Both are pretty nitpicky points, I admit, but then interpreting URLs
      is always a pretty nitpicky process... I did have the JSON Schema
      proposal in mind, but didn't want to seem like I was complaining about
      one particular description - after all, the dot-delimited format was
      also how I approached this in the first place, and since I am not
      using JSON Schema myself I'm not sure it's my place to suggest
      changes. I fully appreciate the difficulties in changing a format
      that's already in use!

      One thought I just had is that you can reliably distinguish between
      the two formats if the slash-delimited format is change to REQUIRE a
      leading slash in the slash-delimited format. That is, because you
      require that the fragment be a list of dot-delimited
      URI-encoded(-with-dots-encoded) keys, you have already forbidden the
      use of a slash in the fragment, since a slash is a reserved character
      that must be URI-encoded. So the two don't necessarily need to
      conflict. I'm not necessarily saying that an implementation would have
      to understand both (although it could), but it could at least
      distinguish between the two and give an error if it encounters the
      format it doesn't understand. I'll have to think about that... I said
      before that a leading slash was unnecessary because fragments refer to
      navigation from the top of a resource, but it's at least analogous to
      the leading slash in a filesystem path or in the path section of a

      There is some potential for allowing a number of different,
      non-conflicting fragment resolution mechanisms indicated by the use of
      a reserve character as the first character in the fragment that way,
      which could be useful for other navigation mechanisms, perhaps
      JSONPath for instance. Again, those wouldn't conflict with the strict
      interpretation of the dot-delimited format.

      On Fri, Feb 26, 2010 at 8:06 PM, Kris Zyp <kriszyp@...> wrote:
      > [+restful-json]
      > Jacob,
      > You may already be aware of this, but a specification for the dot-delimited hash/fragment resolution mechanism is in the JSON Schema I-D (6.2.1) [1]. One thing to be noted that you can specify alternate hash/fragment resolution mechanisms in the schema, the draft just defines dot-delimited as the default. However, we do certainly want the default to be legitimate. I'd be glad to change the draft to slashes if there is consensus that using slashes is more appropriate. However, based on prior conversations [2], I had thought that there was agreement that the stipulations of RFC 3986 didn't need to be strictly applied to hashes, since they aren't transferred over the wire and don't identify resources (they identify internal parts of a resource, and the text you quoted from RFC 3986 refers to how resources are identified). I am certainly open to the idea that slashes might be better though, but since dots are currently in use, I would only want to alter the JSON schema draft if there is sufficient reason.
      > [1] http://tools.ietf.org/html/draft-zyp-json-schema-01#section-6.2.1
      > [2] http://groups.google.com/group/restful-json/browse_thread/thread/e3fd36625bb71d01
      > Thanks,
      > Kris
      > --
      > Thanks,
      > Kris

    • Show all 5 messages in this topic