[microformats-discuss] XFN in Atom

Tantek Ç elik tantek at cs.stanford.edu
Sat Sep 17 16:16:02 PDT 2005

On 9/17/05 12:54 PM, "Luke Arno" <luke.arno at gmail.com> wrote:

> I am trying to get my head around microformats still.

Hi Luke, welcome to the list!

> I asked this already but I think it got lost in the previous thread.
> Does it make sense to do this:
> <atom:link 
> atom:rel="contact"
> atom:href="http://examle.org/hCard.html"
> atom:type="text/xhtml"/>

I believe you don't actually need the namespace qualifiers on the
attributes, since the attributes belong to the element rather than the
global atom namespace.  Also, text/xhtml is not a registered mimetype AFAIK.

 type="text/html" />

Now, that being said,

I'm not sure what you're trying to express with that link.

I.e. what content problem are you trying to solve?

Are you trying to state that you consider the person represented by
http://example.org/hCard.html to be a "contact"?

If so, then yes, that could make sense.

> As a side note, has there been considerations of using the IANA registry for
> rel values.

Not yet, but it's a reasonable proposal to consider.

To date, W3C has kept the "canonical" list of rel values.  They're adding a
few in XHTML2, e.g. rel="profile", which we're thinking of making explicit
even independent of XHTML2 (i.e. before it progresses all the way to REC).

E.g. in your above example, in order to explicitly indicate that you were
using the XFN 1.1 profile to define the rel="contact" value, you could
include the following:

<atom:link rel="profile" href="http://gmpg.org/xfn/11" />

> Could prefixing help avoid conflicts going forward (rel="
> xfn.contact"?)

If conflicts were a real problem to worry about.  Certainly for experimental
values, or odd values for very specialized applications, one might want to
consider some form of prefixing to discourage both premature adoption, and
adoption outside the particular uses you are thinking of.  But for general
purpose 80/20 applications, we have found that such prefixes are
unnecessary/undesirable and nothing but syntactic vinegar that are to be

> Like I said, I am just trying to get my head around this.

Once again, welcome Luke.  Keep asking good questions.



More information about the microformats-discuss mailing list