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

Re: [apps-discuss] New Version Notification for draft-nottingham-link-hint-00.txt

Expand Messages
  • Erik Wilde
    hello mark. ... i guess that s true. but i have to admit that i am struggling a bit with that specific hint anyway. it can hint at links you might find at the
    Message 1 of 12 , Jul 5, 2013
      hello mark.

      On 2013-07-04 3:30 , Mark Nottingham wrote:
      >> none of these representations would be binding, they would just be one way of mapping the abstract link hint model into some concrete model. i guess the only exception for this would be how to represent links outside of media types, i.e. in HTTP. http://tools.ietf.org/html/draft-nottingham-link-hint-00#appendix-A could be changed then to map the abstract moden into a concrete JSON syntax (or whatever else looks like a good syntax choice to go into a Link header).
      > I'm all for that, IF we can be reasonably sure that the current data can fit comfortably into that simplified model.
      > The current hints that use "complex" objects are (keeping in mind that we've just started):
      > - formats
      > - links
      > - accept-post (same format as formats)
      > - auth-schemes
      > Formats and accept-post COULD specify a list of strings, and state that it's either a media type OR a profile URI. This means we'd need a separate representation format for profiles, which would need to convey a media type.
      > This is certainly possible, but the downsides I see are:
      > - It's baking in profiles in at a pretty high level. I like some aspects of profiles, but they certainly haven't taken off in mindshare yet.
      > - Parsing the string to check which it is is nasty.
      > For auth-schemes, we'd need to specify a tuple, probably. Not great, but OK. Extensibility would be right out the window, though, which may be significant for some schemes.
      > Links are fundamentally not possible without some really ugly mapping to a string, I think.

      i guess that's true. but i have to admit that i am struggling a bit with
      that specific hint anyway. it can hint at links you might find at the
      target resource. it may contain hints, so it can also contain link
      hints. so in theory, you could build a multi-level structure of links to
      be expected several link traversals away, right?

      more generally speaking, i am having troubles rationalizing hints that
      give me some "preview" of the target resource. my personal mental model
      of link hints is that they constrain interactions with the target
      resource, but really don't tell you what to expect.

      is http://tools.ietf.org/html/draft-nottingham-json-home-03#section-9
      (the separation into "resource" and "representation" hints in the home
      draft, where the link hint idea started) what might make te difference
      between hints talking about interactions, and hints talking about the
      result of an interaction?

      > My concern is that this is starting not to meet my use cases for json-home, which is where link-hints comes from.

      that would be bad, but again, i am struggling a bit with the hints that
      tell you what to expect, and not just what to do. my thoughts were that
      hints should just be about what to do; do you have a different model in

      > While I could address this by making those things NOT link hints, but other "bumps" on json-home, it would make it significantly more complex. That seems like a poor tradeoff, considering that it's *possible* to map generic hints into XML, it's just not "pretty."
      > To be brutally frank (and I'm sure this isn't going to surprise you too much, dret ;) I don't see a lot of value in catering to the XML API market; it's dying, and introducing constraints on the JSON APIs seems like a bad tradeoff.

      yes, i am not overly surprised ;) but i am not really trying to optimize
      this for XML, i just try to make it more workable for non-JSON consumers
      in general. and i am still hoping that somebody will be able to point to
      prior decisions that were made in similar situations: are there IANA
      registries that are using JSON as a data model for their entries, and
      which other approaches were taken in cases where registries attempted to
      register structured entries? maybe we should just use ASN.1... ;-)

      > I absolutely acknowledge that JSON will one day face its own demise, and will be in a similar situation, but planning for that seems like premature optimisation to me.

      sure, and if the consensus is that it's ok to have JSON-based
      registries, then this is how it is. personally, i think i will then use
      serialized JSON in XML representations, which are a little less horrible
      to look at than generic JSON serialized in JSON.

      >> but again, of course my option (c) means that link hints have a predefined and probably small set of structures that hints can use to expose whatever they want to expose, and if they want to go beyond that, that's not covered by the link hint framework anymore.
      > Yes. That's what I'm struggling with. We're already seeing a number of places that chafe against these constraints, and we're just getting started.
      > What do other folks think?

      good point, so far it's just mark and me. anybody who faced similar
      design issues who could share their considerations and decisions?

      thanks and cheers,


      erik wilde | mailto:dret@... - tel:+1-510-2061079 |
      | UC Berkeley - School of Information (ISchool) |
      | http://dret.net/netdret http://twitter.com/dret |
    Your message has been successfully submitted and would be delivered to recipients shortly.