[microformats-discuss] XFN in Atom
luke.arno at gmail.com
Sat Sep 17 18:13:54 PDT 2005
On 9/17/05, Tantek Çelik <tantek at cs.stanford.edu> wrote:
> 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
> type="text/html" />
That _was_ a poor and hastily composed example. <blush/>
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.
Yes. I am toying with the idea of including social network info via XFN into
> As a side note, has there been considerations of using the IANA registry
> > 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).
Cool. That is much nicer than the head at profile thing (and makes sense in
more types of documents).
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" />
Ah, yes. That is it.
> Could prefixing help avoid conflicts going forward (rel="
> > xfn.contact"?)
> If conflicts were a real problem to worry about. Certainly for
> 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
I see your point. I suppose it would run counter to the spirit of
> Like I said, I am just trying to get my head around this.
> Once again, welcome Luke. Keep asking good questions.
Thank you (and Ryan King) for the welcome. This is very exciting stuff.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the microformats-discuss