Re: [uf-discuss] OpenID delegation and XFN
According to [1] it's fine sticking rel attribute in link elements so I don't see why not, generally. But read on. I would even extend the question why not adding rev=me since that url should be mine as well but,this [2] proved me wrong.. [1] http://www.w3.org/TR/html401/struct/links.html#edef-LINK [2] http://microformats.org/wiki/rel-faq#Should_rev_even_be_used I would like to add though, that the only situation where I see this making sense would be when the user would like to have a certain page related with all others social networks ( or more general, his/her presences on the web) and not show that information. (just hiding it with css smells funny to me). Summarizing: Case #1: User wants to connect his page with a bunch of others but doesn't want that explicitly stated on the page = user includes links with rel=me attribute. Case #2; User wants to create a landing page for himself and explicitly state his other presences out in the open, for everyone to see = user includes a with rel=me attribute. Final Note: This could bring problems to certain implementations that would search the DOM document for all A elements and not A and LINK. I'm not sure whether this situation has been discussed earlier in the list or is in the wiki. If so, I'd be thankful if someone could point me there. Cheers, André Luís On 10/13/07, Chris Messina [EMAIL PROTECTED] wrote: Will Norris made a great suggesting for making OpenID delegation links compatible with XFN rel-me links. I actually think that it's okay to use link /'s in the header of a document to point to other social networks and so on... I understand that this is not kosher with marking up visible data, but if it's going to be there anyway (and it's part of the OpenID spec) we might as well markup the links in the microformats format: link rel=openid.server href=http://www.myopenid.com/server; / link rel=openid.delegate me href=http://will.norris.name/; / Thoughts on this? I know that I'll get push back, but logically why not this? link rel=me href=http://flickr.com/photos/factoryjoe; / link rel=me href=http://ma.gnolia.com/people/factoryjoe; / Chris -- Chris Messina Citizen Provocateur Open Source Advocate-at-Large Work: http://citizenagency.com Blog: http://factoryjoe.com/blog Cell: 412 225-1051 IM: factoryjoe This email is: [ ] bloggable[X] ask first [ ] private ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] OpenID delegation and XFN
On 10/13/07, Chris Messina [EMAIL PROTECTED] wrote: Will Norris made a great suggesting for making OpenID delegation links compatible with XFN rel-me links. I actually think that it's okay to use link /'s in the header of a document to point to other social networks and so on... I understand that this is not kosher with marking up visible data, but if it's going to be there anyway (and it's part of the OpenID spec) we might as well markup the links in the microformats format: link rel=openid.server href=http://www.myopenid.com/server; / link rel=openid.delegate me href=http://will.norris.name/; / Thoughts on this? I know that I'll get push back, but logically why not this? link rel=me href=http://flickr.com/photos/factoryjoe; / link rel=me href=http://ma.gnolia.com/people/factoryjoe; / Logically, sure, fine. Practically, one might need to check that OpenID libraries are parsing the HTML properly (the XFN tools will be fine, since they are coded with multiple values in mind) - the programmer may have neglected to look for space-separated values inside the rel value. I know I'd have to edit the source of an OpenID function I wrote a while back. GrokXFN.xsl (the GRDDL parser for XFN) only looks in 'a' elements for XFN links. I'm not sure about other parsers (and it's 2am, so I'm not lookin'...) I think it's a good idea. Visible meta-data is a good idea, but not an absolute requirement. (Of course, all data is visible - 'View Source'). Putting microformats on head/link elements is fine, in my book. The more data, the merrier. -- Tom Morris http://tommorris.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
