Re: [apps-discuss] Feedback on draft-wilde-profile-link-00

[Mark Nottingham <[e-mail]>]

On 06/04/2012, at 2:18 PM, Erik Wilde wrote:

>> That's a good design, because link relations are already a defined mechanism to talk about resource behaviours; having two such mechanisms isn't a good idea (at least without some discussion).
>> E.g., when I interact with a resource, I know it supports particular behaviours, because it's been linked to with relation "Foo." When I get a representation from the "Foo" resource, it will have a media type that describes the format, and also a profile ("Bar") that describes additional features / conventions of that document (such as a particular use of JSON or XML), but that profile won't -- and shouldn't! -- be an additional way of describing the behaviours of the "Foo" resource.
> 
> now i am little bit confused. taking your example, i am not concerned with the link relation that was used to discover 'foo' at all. all i am concerned with is that if i am retrieving 'foo' and i find a 'bar' profile identifier in the representation, i know that it follows constraints and conventions beyond the 'foo' media type.

Yup.

> one example i am currently considering adding is atompub. currently, when you retrieve a feed, there's no way to tell it's atompub-capable just by looking at it.

Well, what thing in this case is atom pub capable? The format that the links are occurring within, or the targets of the links themselves? I'd argue the latter. You can take that argument too far, of course, but generally I see profiles as describing format conventions, and link relations as describing behaviours of resources. Of course, some of those behaviours can be "produce this format" and some of the formatting conventions can be "link to something with this behaviour".

Am happy to be proven wrong on this, I just think we need good patterns of use / best practices to encourage reasonable design.

Make sense?

--
Mark Nottingham
http://www.mnot.net/