Re: request to register 'profile' link relation (http://tools.ietf.org/html/draft-wilde-profile-link-03)

hello andrei.

On 2012-09-25 1:16 , Andrei Neculau wrote:
> #1 is there somewhere that says that a describedby link should be
> dereferenced _automatically_ when encountered? (that is what you're
> saying, right? i mean, you should be able to dereference all links)

the assumption for 'describedby' is that when you follow the link, you 
find a description resource. there is no such thing as 'automatic link 
following', but the link relation can tell you what typical interactions 
look like. for 'describedby', it's following the link. for 'profile', 
it's comparing the link target to known identifiers. maybe reading 
http://www.w3.org/TR/html4/struct/global.html#profiles helps?

> This description makes me think that although describedby is not very
> specific, it can be very well used to point out what type of constraints
> this resource/media-type abides (e.g. json schema) - while you could
> very well have only a literal description in plain text.

yes, it could. and there's always some leeway in deciding how generic a 
link relation should be (you want some level of reusability, but also 
some level of defined semantics). you could use 'describedby' to link to 
schemas/types, like you say, and we're actually having an internal 
discussion whether we'd like to use describedby for exactly that purpose 
or not, but there's no single correct answer here.

> #3 when you say " the intention is not that clients should follow that
> link; the semantics are in the identifier itself", I guess you refer to
> both a link with rel=profile (in the Link header or in the payload), and
> to the profile param of a media-type ?

i refer to wherever that link relation is used.

> I can understand that as a param to a media-type, it acts as an
> identifier, just like the media-type itself "application/json" or
> "application/vnd.andrei+json"
> but as a link, it has to be "deference-able", so that the client can
> follow it. Otherwise, and maybe I am wrong, but it is not a link anymore.

a link establishes a (typed) relationship between two identified 
resources. whether the URIs can/should be dereferenced or not is a 
separate issue.

> #4 "resource follows additional conventions"
> If I have a media-type "application/vnd.andrei+json" - which under
> http://tools.ietf.org/html/draft-ietf-appsawg-media-type-suffix-regs-04
> means that it has JSON syntax, and some additional semantics of
> "vnd.andrei". Accepting such a media-type means that the client is
> already aware of such syntax and semantics, so pointing the client to
> "additional conventions" is not really the term here. Instead I would
> say that this link (may it be describeby or profile) is a description of
> those conventions which are already shared between server and client
> i.e. a json schema of application/vnd.andrei+json

if you have a media type and that's all you need, then you don't need 
profiles. if you have a media type that has some openness to it and you 
want a way how to communicate about how this openness is used, then 
maybe profiles can be useful for you. again, consider HTML's example.

cheers,

dret.

-- 
erik wilde | mailto:[email protected]  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |