« Action URIs | Main | REST Layers and REST Applications »

Monday, March 05, 2012


Feed You can follow this conversation by subscribing to the comment feed for this post.

Stefan Tilkov

We continuously run into the problem of both wanting to re-use an existing media type and wanting to specify additional semantics. I'm only aware of the +xml approach (which is only defined for XML), so yes, I think this would be a good idea.

One downside as opposed to "just" using media types, though, is that the client can't specify a type/format/set of semantics as part of its request. I'm not sure how this could be addressed.

I'm sure you are aware of this old discussion regarding augmenting media types [1] and a related 105-post-megathread on rest-discuss [2]?

[1] http://www.innoq.com/blog/st/2008/02/decentralizing_media_types.html
[2] http://tech.groups.yahoo.com/group/rest-discuss/message/11734


stefan, thanks for the comment! yes, the "+xml" approach is one thing to keep in mind, but it really does not work all that well, because it has all kinds of magic built-in and is more of a one-time thing than even a convention that could be easily and robustly reused. one simple example for this is the question of how it can be nested. lets look at application/xml and application/atom+xml, which is using the "+xml" convention. now let's say i want to create a "podcast" profile (assuming for a minute that podcasts use atom instead of rss). i could use application/podcast+atom or maybe even application/podcast+atom+xml, but i am not sure that i like where this is going. and frankly, the whole media types space lacks any kind of extensibility and coherent design approach so badly that i would hesitate to even try to touch it. and i am still not sure how much real benefit "+xml" really has delivered in addition to creating the illusion that there is some logic to how media types can be related. i am open to suggestions, but from what we've looked at in our use cases, not touching media types at all and instead expressing the relationship in a self-describing way within representations seems like the better way to go.

Danny Ayers

rel="profile" I don't understand! (not helped by the fact the microformats wiki isn't loading for me)
Ok, "such a link serves as an identifier that a resource representation follows additional constraints or rules" - but where are the constraints/rules specified? Or is the href URI the profile, in which case, to what does it apply?

Incidentally the neatest use of doc-level profiles I've seen is in:

the recursive, "follow your nose" part is cunning (and Webby)


danny, thanks for the comment! let's look at the podcast example again (again assuming they use atom). if you go to a feed and that feed says , then you know it's a podcast (assuming we had the "profile" link relation type and apple's podcast spec would say that the podcast "namespace" is http://www.apple.com/itunes/podcasts/). in general whether the profile URI is dereferencable or not is optional, in the same way as with XML namespace URIs (and to what it resolves if it does resolve is also not specified). it identifies a profile by the virtue of URIs being the web's identifiers, and that's it. it would be helpful to actually provide a resource, and some communities might even invent their own profile description specs (i could see the microformat community creating one, and the RDF community creating another one), but that's optional. at some level, you could look at the profile URI as something fairly close to an XML namespace URI: it identifies additional constraints that might help clients to better understand the resource. but the profile link relation type is independent of the media type, and thus can be used for all kinds of media types that wish to signal the fact that a resource carries additional semantics.

Erlend Hamnaberg

+1 This would be generally useful

Danny Ayers

Thanks Erik, sorry, I obviously wasn't clear. I get the idea of using a doc-level profile (in fact I was on the GRDDL WG mentioned above), what I didn't get was specifically the use of rel="profile". But the podcast example helps, I assume this is what you mean (square brackets because I've been bitten by too many comment systems:) :

[feed xmlns="http://www.w3.org/2005/Atom"]
[title]Example Feed[/title]
[link href="http://www.apple.com/itunes/podcasts/" rel="profile" /]
- means "this feed is a podcast feed" (and presumably the same construct could be used on individual entries)

I suppose given that link rels are fairly well established, rel="profile" (with href="uri") could be a more portable specification that the more direct profile="uri".

What confused me was that other big use of rel values, how would [a href="uri" rel="profile"]text[/a] be interpreted? (I assume it simply wouldn't be used this way).


danny: a link relation type can be safely used in any media type that supports typed links, and that is a significant subset of media types. most importantly, you don't need to update the media types in any way, whereas you would need to do that for adding profile attributes to media types (and for non-XML media types it would not even be clear how to do that).

for the [a href="" rel="profile"/] example you're right that this would usually not be the place where a profile link would occur. for HTML, it usually would be a [link rel="profile" href=""/] in the document head, and for other formats (such as atom) it would generally be whereever resource-level links are supported. it also would be possible for HTTP Link headers to contain profile links, thereby indicating on the HTTP level which profile a resource conforms to (might be useful for PDF, for example, where on the HTTP level a server could indicate that a PDF indeed was a PDF/A, if there were a URI identifying this particular PDF profile.

Peter Rushforth


The head@profile is used by opensearch autodiscovery http://www.opensearch.org/Specifications/OpenSearch/1.1#Autodiscovery_in_HTML.2FXHTML

I think in practice it is the @rel="search" that drives the client to the discovery document, but maybe the profile helps.

I wonder/worry that a profile link relation is playing the role of some part of what media types are supposed to do, and I wonder if we shouldn't think along the lines of how to use MIME media type parameters to perform this function.

My concern stems from my interpretation of this http://www.w3.org/2001/tag/doc/mime-respect.html#why.
Whereas REST pours a lot of importance into Accept and Content-type message metadata, yielding "self-describing messages", a profile link relation is a) a reference, the object of which is therefore subject to change without informing the agent at run time and b) seems to be meant to be embedded in the message body which, in the absence of message metadata leads to sniffing, which I think defeats some of the benefits of REST.



thanks for your comment, @peter. referring to a), a profile link very specifically is defined to not be a reference, it's an identifier (please refer to the 3rd paragraph in http://tools.ietf.org/html/draft-wilde-profile-link-01#section-3). referring to b), you're right that it is embedded and thus not readily available at the HTTP level. however, using Link: headers, you can express profiles on the HTTP level as well.

it would be good to add profile parameters as media type parameters, and i am planning on making that recommendation in future versions of the draft. but as @mnot pointed out to me, you cannot retroactively do that, so even though HTML uses profiles, you cannot change the media type registration without re-registering the media type with a profile parameter. but apart from that technicality, i absolutely agree that any media type supporting profile links should specify a media type parameter as well.


Regarding the profile media type parameter, javax.activation.MediaType does not permit URIs in the value of parameters. Not sure if that follows the current media type RFC, but the javadoc http://docs.oracle.com/javaee/5/api/javax/activation/MimeTypeParameterList.html#parse(java.lang.String) claims to follow RFC 2045, 2046. pct-encoding seems to workaround the issue.


good point, @peter. http://tools.ietf.org/html/rfc2045#section-5.1 seems to say you have to quote them (any non-token parameter value needs to be a quoted-string). quoted-string is imported from RFC 822, where it's defined here: http://tools.ietf.org/html/rfc822#section-3.3 ; so i am pretty confident that following the proper encoding rules, this can be done. but thanks for pointing it out, and maybe i could sneak in a minor edit into the final version to mention this.

The comments to this entry are closed.