one of the not-so-well-known features of HTML is the ability to specify a profile attribute for a web page. it goes right in the head element like this: <head profile=" some URI ">. here is what the HTML spec says about this attribute:
This attribute specifies the location of one or more meta data profiles, separated by white space. For future extensions, user agents should consider the value to be a list even though this specification only considers the first URI to be significant. Profiles are discussed below in the section on meta data.
The profile attribute of the HEAD specifies the location of a meta data profile. The value of the profile attribute is a URI. User agents may use this URI in two ways:
- As a globally unique name. User agents may be able to recognize the name (without actually retrieving the profile) and perform some activity based on known conventions for that profile. For instance, search engines could provide an interface for searching through catalogs of HTML documents, where these documents all use the same profile for representing catalog entries.
- As a link. User agents may dereference the URI and perform some activity based on the actual definitions within the profile (e.g., authorize the usage of the profile within the current HTML document). This specification does not define formats for profiles.
the HTML profile attribute is defined so that it may contain white-space separated URIs, each of them identifying one profile. this is a bit unconventional, but the overall design goal is clear and reasonable: why restrict a web page to only conform to one profile? in practice, though, the profile attribute is hardly ever used, and if people know of any deployments where it is actually being used by clients, please make sure to point to this in a comment!
in our work on RESTful services, we have repeatedly run into the situation where we want to have a runtime mechanism how a resource can represent the fact that it follows additional constraints and/or rules. creating media types at runtime is not such a great idea, and it would also not allow us to represent the fact that a resource is still using a representation based on some media type, but also can be treated according to additional constraints and/or rules. a profile mechanism would be a good way of doing this, and thus we would like it to become a recognized link relation type.
seeing that profiles are a good idea, but should not be restricted to HTML and thus be represented in a more generic way, microformats.org published a proposal for a
relation type a while ago. this is a good initiative, but there are two downsides to the current microformat proposal:profile
- it is not intended to register the
link relation type in the IANA link relation type registry as defined by RFC5988. it would be useful to have this link relation type standardized at the web level.profile - the proposal makes assumptions about the linked resources and the processing model for them. instead, it should be left to media types (the ones using/supporting profiles and possibly profile media types themselves) to makes these assumptions, so that the link relation is decoupled from media type specifics.
this means that it might be a good idea to push forward with an I-D proposal to standardize a
link relation type. This relation type would state that such a link serves as an identifier that a resource representation follows additional constraints or rules, so that clients processing it could take those into account. whether the link is dereferencable at all and if so, what kind of resource it would point to, would be left open. this blog post is soliciting feedback about this idea, and any profileyes, this would be a good idea, please make it happen!
or no, this is a bad idea and here is why
comment is welcome. depending on the feedback, i'll continue with my work to publish an initial draft, which should be out in the next week or two.
[[ update 2012-04-15: there now is a draft out, draft-wilde-profile-link is available through the IETF site (and the IETF datatracker), and as of today has been updated to version 01. ]]
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
Posted by: Stefan Tilkov | Monday, March 05, 2012 at 13:46
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.
Posted by: dret | Monday, March 05, 2012 at 15:08
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:
http://www.w3.org/TR/grddl/
the recursive, "follow your nose" part is cunning (and Webby)
http://www.w3.org/TR/grddl/#sec_agt
Posted by: Danny Ayers | Monday, March 05, 2012 at 15:25
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.
Posted by: dret | Monday, March 05, 2012 at 15:36
+1 This would be generally useful
Posted by: Erlend Hamnaberg | Tuesday, March 06, 2012 at 00:41
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).
Posted by: Danny Ayers | Tuesday, March 06, 2012 at 03:57
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.
Posted by: dret | Tuesday, March 06, 2012 at 09:44
Erik,
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.
Peter
Posted by: Peter Rushforth | Friday, May 11, 2012 at 17:53
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.
Posted by: dret | Friday, May 11, 2012 at 22:53
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.
Posted by: Peter | Thursday, February 07, 2013 at 08:38
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.
Posted by: dret | Thursday, February 07, 2013 at 09:20