profile-uris: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
m (: hDOAP)
No edit summary
Line 1: Line 1:
<h1>Profile URIs</h1>
<entry-title>Profile URIs</entry-title>

Revision as of 16:53, 17 November 2008

<entry-title>Profile URIs</entry-title>


In hCalendar issues, it is ACCEPTED that each microformat should have a profile URI, like the XFN profile.

Known URIs

This section lists known profile URIs for microformats. To promote cacheability and recognisability of profile URIs, authors SHOULD avoid minting new URIs for existing microformats, and SHOULD re-use existing well-known profile URIs.

Combined Profile

The following URL covers all non-draft Microformats as of March 2008, except XMDP. You can mix and match it with other XMDP profiles for new/draft microformats.

Individual Microformats

(Use an hCard profile.)
(Or use the combined profile.)
(Or use an hCard profile.)
(Or use the combined profile.)
hCalendar ¶†
(Or use the combined profile.)
(Or use the combined profile.)
(Or use the combined profile.)
(Or use the combined profile.)
(Or use the combined profile.)
VoteLinks ¶†
(Or use the combined profile.)
XFN (older version)
(Or use the combined profile.)
(Use the combined profile.)

† = GRDDL-enabled.
¶ = non-XMDP profile.

Other Interesting Profile URIs

How to link to a profile URI

<head profile>

This is the original method of linking to profile URIs and is currently supported by the greatest number of tools. This is valid in HTML 4 and XHTML 1.x, but is not valid in Atom (as Atom has no <head> element) or current drafts of HTML 5 and XHTML 2.


  <head profile="">


An alternative method is provided for people using markup languages which do not support <head profile>. Add rel="profile" to either a visible link (<a>) or hidden link (<link>).


<p>This page uses
<a rel="profile" href="">XFN 1.1</a>!</p>



Tools that support GRDDL use profiles to parse microformats.


In "strict mode", Cognition refuses to parse any microformats where the profile URI has not been explicitly declared on the page. (It will however, still parse microformats for which there exists no profile URI!)


Some issues include:

  • what domain to use? Candidates include:
  • what about versioning? How to keep in sync with the wiki and test materials?
  • what profile URI to use for combinations, such as hCard 1.0 and hCalendar 1.0?
    • note HTML4.01 states "that one or more meta data profiles, [are] separated by white space"; though it's simpler for authors if they can just use one profile URI.
  • More profiles are needed.

One proposal is: use, following W3C namespace policy. As to versioning, change the profile whenever the wiki changes (within some reasonable latency, say, a couple weeks or a month). For example: an hCard Profile at, and discussion: an hCard profile that seems to work with GRDDL.

Validator warning

Due to inconsistent wording of the HTML specs, HTMLTidy (and other tools?) give "Warning: <head> escaping malformed URI reference" when more than one profile is used, e.g.

<head profile="">

W3C HTML validator has very poor validation of attributes and is technically unable to check this case. The HTML DTD however defines profile attribute as %URI (it's an alias for CDATA), same as <a href> attribute.

See also