From Microformats Wiki
Revision as of 19:26, 4 September 2007 by Tantek (talk | contribs) (added * footnote about not scaling)
Jump to navigation Jump to search


This page is for documenting Q&A about XFN in addition to the official XFN FAQ. It is likely that items here will be incorporated there. Or perhaps GMPG may choose to redirect the FAQ here - this is to be determined. For now, if you have a new question to ask about XFN, please consider first asking your question on the microformats-discuss mailing list.

Please first read the official XFN FAQ.


Why is muse in the romantic category

According to the XFN spec, rel="muse" is a link to someone who inspires you, and is listed as being a "romantic" relationship. Does it is always implied as a romantic relationship, since one could certainly find someone else inspiring without being romantically involved/interested?

  • Certainly "muse" was not intended to only be purely romantic in the literal "romantic relationship" sense (though it is clear how that could easily be misconstrued), and of course that meaning is included. The categorization as "romantic" is in a broader sense, similar to romanticism as in enabling the elevation of:

    "the achievements of what it [Romanticism] perceived as misunderstood heroic individuals and artists that altered society."

    or romance the genre.
  • The XFN spec defines muse as well as crush, and one ought not to be confused with the other. Either way, romantically or figuratively, the muse inspires.
  • Note also: The Wiktionary definition of muse

Why not use rev instead of a keyword to denote the reverse

Why not exploit the rev property to avoid having to use a different keyword to denote the reverse? --Jon Williams 14:41, 8 Jan 2007 (PST)

Can XFN links use protocols other than http

Can you use rel="me" for other protocols besides HTTP? such as mailto: or aim:? --Brian Suda 03:37, 2006-05-12 (PST)

  • The current answer is "yes" particular because XFN only described the relationship between two things, rather than the protocol with which either thing is addressed.

Does consolidating a paginated friends list scale

Note: this is an implementation FAQ.

How do services that publish hCard+XFN supporting friends lists and use the rel="me next" and rel="me prev" method for consolidating paginated friends lists scale?

The short answer is: it is pagination that actually scales and publishing complete lists that does not.

In real world practical experience, Twitter's live-on-the-web implementation right now has demonstrated not only that the pagination approach already scales, BUT more importantly:

"publishing all your friends on one resource" DOES NOT scale.*

Twitter employee Blaine said as much at the Social Network Portability Today meetup at the Satisfactory, due primarily to database load.

Note that because this is a backend issues, this is true regardless of the format sent to the front end client (whether HTML, random XML, or CSV). And whether you call it an "API call" or "HTTP GET request" or "page load", on the Web they are all the same thing.

Note also that this isn't uncommon. Twitter isn't the only interface (whether user or programmatic) that requires clients (whether browsers or spiders) to retrieve paginated results. Most search engine APIs for example require clients to make paginated requests.

  • Any such absolute statement ("does not scale") is obviously meant to summarize a measured result rather than be dogmatic in nature because obviously in the literal sense such an unqualified absolute statement can be disproven with carefully chosen examples. In this instance, it has been pointed out that there are services (namely LiveJournal) that can return hundreds of contacts in a single request without any difficulty. Problems have been noted by implementers (e.g. Twitter) when a friends list has more than about 1500 contacts, especially trending into the 10,000 range. With modern (as of 2007) servers and backend software stacks, returning simple datasets this size can take over a second if not cached, which is too long.

See Also