Re: New Version Notification for draft-nottingham-link-hint-00.txt

Hi Erik, and Mark,

On 05/07/2013 16:00, Erik Wilde wrote:
>>> 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?

I'm interested in the json-home work, and I've had discussions with both of you 
separately about using RDF for something similar.  That's the route we followed 
in PROV-AQ (http://www.w3.org/TR/prov-aq/#provenance-query-service-description).

I haven't really been following this link-hint discussion, though I can see it's 
related to the home document in light of discussions we had about the role of 
link relations ("why" vs "how", etc).  In this general context, having some idea 
of what types are available to content negotiate seems useful.

Beyond that, for applications that choose to use RDF (in one of its available 
media types), or a similar generic format, to describe services might benefit 
from some additional indication of whether there is likely to be anything of use 
to them ... but as you pointed out this tends to increase coupling, trading REST 
flexibility for possible more efficient discovery.  This leaves me wondering if 
link hints might not be a form of premature optimization that might be better 
achieved through caching of responses?  (Just a thought, not a claim.)

[Later]

I just (re)read the draft, and it occurs to me that most of these hints are 
things that can or might be provided by header fields in a server response. 
That suggests a possibility that a generic data model for representing hints 
might usefully be based closely based on the HTTP/MIME header field model.  In 
many respects, the proposal's use of key-value pairs does make it closely 
aligned.  It seems to me that the main thing missing may be a model for 
representing a header (i.e. multiple header fields) within a header field - 
which I think is where JSON objects are being used.

#g
--