rel="profile" was originally introduced in a draft of XHTML 2.0 (citation needed) as a result of a proposal by Tantek Çelik during an early HTML Working Group meeting (sometime in the early 2000s, working group minutes citation needed) to solve the problem of profile URLs being limited to a single one-off invisible attribute of the
This same meaning, that of a link to a metadata profile for the current document, is has been incorporated into XMDP since Microformats in HTML5 drops the "profile" attribute. See also XMDP Brainstorming, in particular, when microformats may be in use.
- Tantek Çelik
In brief: the head[profile] takes precedence per current XMDP description (for backward compat), and then the same first defined rules apply, that is in cases where more than one profile from an
<a rel="profile"> defines the same term, first definition wins.
- All processors MUST use the DOM of a document parsed per HTML5 or an algorithm that provides an equivalent result. All references to elements, attributes, accessing, traversing refer to in the context of the DOM. All processing steps are required (Template:MUST) unless otherwise specified.
Processing model for determing the profile dictionary for a document:
- rel-profile processors start with an empty profile dictionary for the document consisting of terms and respective definitions and list of links.
- rel-profile processors SHOULD for backward compatibility access the 'profile' attribute of the 'head' element, treat it as a space separated list of profile document absolute (fully-qualified) URLs, and process them in order as profile links.
- rel-profile processors MUST access 'link' elements in the 'head' element in document order and if their 'rel' attribute, when treated as a space separated set of keywords, contains "profile", process the 'link' element's 'href' attribute per HTML5 URL resolution rules as a profile link.
- process these profile links into a profile dictionary for the document.
Processing model to process a profile link into a profile dictionary
- retrieve the profile link as a profile document
- parse the profile document per HTML5 parsing or an algorithm that provides an equivalent DOM result and use that DOM for further processing of the profile document.
- access 'dl' elements in the profile document in document order and if their 'class' attribute, when treated as a space separated set of keywords, contains "profile", process the dl as a profile definition list.
- access 'dt' children of the profile definition list in document order and if their 'id' attribute is non-empty, process the dt as a profile term
- access the text contents of the profile definition term, and if it is not present in the dictionary table, add it and process following sibling 'dd' elements as profile term descriptions until the next 'dt' element or the end of the profile definition list whichever comes first.
- access the text contents of the profile term descriptions, concatenate them with an intervening whitespace " " character, and place them in the profile dictionary as the definition corresponding to the profile definition term
- start with a new list of links. access the hyperlink (a href) descendants of the profile term descriptions in document order and for each one, if their 'rel' attribute, when treated as a space separated set of keywords, contains "help", process its 'href' attribute per HTML5 URL resolution rules and add it to a the list of links. Place the complete list of links from this step for this profile defintion term into the profile dictionary as its corresponding list of links.
Processing model to process rel-profile hyperlinks into a profile dictionary for an element.
- for an element, start with an empty profile dictionary for the element
- retrieve all children hyperlinks (a href elements) in document order and if their 'rel' attribute, when treated as a space separated set of keywords, contains "profile", process the 'a' element's 'href' attribute per HTML5 URL resolution rules as a profile link.
- process these profile links into a profile dictionary for the element
This process creates a profile dictionary for the document, and for each element.
Each element also has an effective profile dictionary, which is determined by combining the profile dictionary of the element and all its ancestors. If a term is defined in multiple profile dictionaries, the definition nearest to the element takes precedence.
The definition of a term within the context of an element may be determined by looking it up in the effective profile dictionary for that element. If the term is not present, then it is undefined.
Using rel="profile" has numerous advantages aside from the obvious and originally intended advantage of enabling HTML5 documents to not depend on the "profile" attribute of the
<head> element, and simply use the existing
<link> element instead. E.g.
<link rel="profile" href="http://gmpg.org/xfn/11" /> <link rel="profile" href="http://microformats.org/profile/hcard" />
Most of these advantages come from the ability to use
<a> hyperlinks instead of (or in addition to)
<link> elements and are based on the microformats principles.
The idea is that a document that uses a particular microformat, e.g. hCard 1.0, can explicitly link to the profile for that microformat and indicate the profile relationship, via existing visible content hyperlink text such as "This document uses hCard", or an hCard badge image, both of which have been seen in real world web content. E.g.
<div class="vcard"> Here is my <a rel="profile" href="http://microformats.org/profile/hcard">hCard</a>: <div class="fn">Tantek Çelik</div> <div class="org">microformats.org</div> </div>
The microformats root class name 'vcard' as well as properties 'fn' and 'org' are defined by the profile http://microformats.org/profile/hcard.
Hyperlinks with rel="profile" provide the potential for contextual definitions of terms. That is, we define vocabularies included by a hyperlink with rel="profile" to apply only within the context of the hyperlink (the parent element and all its descendants).
These fragments of self-defining portable Semantic HTML enable more modular HTML for transclusion and other purposes.
In Atom the
link element can be used inside the
feed element to link to a profile for microformats used in the feed. e.g.:
<feed> <link rel="profile" href="http://microformats.org/profile/hcard" /> ... </feed>
To scope a profile to a specific Atom entry use
<link rel="profile" /> inside that
<entry> element, e.g.:
<entry> <link rel="profile" href="http://microformats.org/profile/hcard" /> ... </entry>
Cognition has supported
rel=profile since March 2008. Cognition has two microformat parsing modes:
- Strict mode: pages using microformats are required to include a well-known profile URI for each microformat they use, essentially as a "flag" to enable parsing of that microformat.
- Loose mode (default): most microformats will be parsed without a profile being explicitly included (though authors are still recommended to include profile URIs for any microformats they use). Some obscure microformats (e.g. XFN 1.0, XEN) still require a profile URI to work.