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:
- 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.
- 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
yes, 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.