>> Hi Eran, > The current draft is pretty clear that the link is between the > conveyed representation of the resource, but what is not clear is to > what. Let's assume 'type' is not present in a Link header. This > means the on one side of the relationship we have a representation > while on the other side we have a resource (as no representation is > specified). This gets more complex if we bring 'type' back in. When type is missing, the server is not providing any hint, and the client can resort to conneg. > > Content-type: text/html > Link: <http://example.com/resource/2>; rel="next"; type="text/html" > > Can mean, this is a link between: > > 1. /resourse/1 and /resource/2 > 2. the text/html representation of /resource/1 and (any > representation of) /resource/2 3. the text/html representation of / > resource/1 and the text/html representation of /resource/2 It is just (1) with the type being a hint to the media type of that resource. > If /resource/2 does not support the text/html representation, then > #3 means a broken link, just as if /resource/2 would return a 404 > with no additional useful information. I don't think the type provides such a guarantee. > > >> Personnally, my hope is that the relations are regarded as holding >> between the resources that are referenced by URIs (as opposed to one >> party to the relation being a more ephemeral representation or >> message >> being conveyed). > > I agree both on simplicity grounds but also because once links are > attached to the context of specific representations, it opens up the > can of worms above, where the link may or may not be symmetric (one > side representation and the other resource). And as demonstrated > above, it put the meaning of 'type' in question. HTML/Atom link elements offer the same kind of flexibility. The source is a representation, and the target could be one of the following: a. A different representation of the same resource b. Another resource c. A specific representation of another resource. Subbu --- http://subbu.orgReceived on Wednesday, 3 December 2008 19:27:01 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:58 GMT