Let’s take a moment to think about the poor developer writing applications to consume this data. All they’re interested in is rel=”contact” and rel=”me” (and foaf:knows). When they come across rel=”crush” what are they going to do? Another google search to find documentation of whether “crush” is a sub-class of “contact”, followed by yet another case statement. I’m all for adding richness and extensibility but not at the expense of the consumer developer. If we’re going to have sub-types then perhaps the markup should be doubled up. Put both in.

Chris says: “And, compared with emails for identifiers, URLs are definitely the future.” Well, yes, but, most of the use cases for contact list portability involve matching up what you find with what you already know. Unfortunately email addresses are rather good for that and URLs less so. In an awful lot of sites the “Home Page URL” field is either missing or gets filled with a generic company URL. That’s not a very good unique identifier. But even though email is not perfect people always have to put it in, and most people use a single email address on all sites. And again, it’s not perfect but mbox_sha1sum is a pretty good way of passing the unique email identifier while reducing it’s openness to abuse. It’s unfortunate that there’s no obvious way of adding it to the xfn markup.

So I love that you’re taking the same approach here. As you know, the Microformats ethos absolutely encourages taking pieces of XFN and spinning it off into XPCL (XHTML Portable Contact Lists), or whatever. In fact, doing so with a v1.0 with just those two values meets the immediate practical needs while also leaving the door open to extensibility in future versions, assuming new values are found to be needed.

Q.v. http://microformats.org/discuss/mail/microformats-discuss/2008-March/011814.html

…