Chris,

(all the following simply thoughts in the spirit of brainstorming, rather than any particular argument in favour of my original suggestion)

I pretty much came up with a very similar proposal for handling this
issue, though from the standpoint of XFN-links, and I think that
John's suggestion is very good, though instead of using "bookmark
self" might suggest "me self" for identifying the One True Hcard:

<div class="vcard" id="vcard">
 <address><a href="http://factoryjoe.com/blog/hcard/#hcard"; class="fn
url" rel="me self">Chris Messina</a></address>
 <div class="org">Citizen Agency</a>
 ...
</div>

I wonder whether hAtom had predated XFN, self instead of me would have been chosen for the identity value?

The "definition" of the self attribute value in Atom is "self: the feed itself". The term "the" seems to indicate "definitiveness". So, I was initially going to argue that "self me" was tautological, but in fact, in this sense it is not, and indeed, the addition of bookmark is probably tautological.

So, I'd probably +1 this suggestion, and perhaps also suggest that for hReview simply a rel value of "self" be required for the permalink, for consistency.

The use of the <address> tag is also important, as it signifies with
additional certainty that the author of the page own the hcards --
making it doubly authoritative.

Thats true. But just to note (as I am sure you know) that as address is an inline element, this enforces certain contraints on its descendents - they al have to be inline elements.

Thus if you can find an object at "address a[rel~=self].url", there's
good chance you've got something pretty solid.

Thoughts? (I've also updated my post to reflect John's suggestion)

I suggest the correct use of self is definitive, so address, while perhaps advisable, doesn't need to be required.

j


Chris

On 1/29/07, John Allsopp <[EMAIL PROTECTED]> wrote:
Ben,

> For my money, John Allsopp's idea to reuse rel="bookmark self" [1]
> makes most sense. As well as being gorgeously consistent with other
> existing microformats, it's also a completely graceful addition to
> existing hCards.

thanks ;-)

There's a lot of goodness to reuse from other ufs, for sure.

> The only concern I can see to check is if this would conflict with
> and break the parsing of hAtom/hReview that already use those rel
> values in combination?

When rel-license is inside an hReview, it is taken to be associated
with the review,  rather than the larger fragment it would otherwise
be associated with (e.g. post or page)

I wonder whether that makes sense more generally - things apply at
the finest level of granularity at which it mkes sense - so
rel="bookmark self" applies to the microformatted content it is most
directly descended from.
Are there reasons people think this is a bad idea?
An analogy again is categories in hAtom

You can have either feed categories or entry categories. Both are
encoded using rel-tag. The difference is that entry categories are
inside the hentry element, while feed categories are in the hFeed
element (but not in the hEntry element). The point is that hEntry
elements descend from hFeed elements, so all entry categories are
inside an hFeed element.

Indeed, Brian Suda, Michael Kaply, or someone else who does a bit of
parsing might weigh in on whether or not this is an implicit
assumption they make more generally with their parsers, or whether it
might become an explicit convention - to try and formulate it (badly)

"where a feature of microformats may apply to more than one element
in a descendent tree, it is associated with the element which most
directly contains it ."

> It would take the guesswork out of parsing, whilst publishing
> useful information. Additionally, what do people think to
> situations where an hCard contains a A/@REL="bookmark self" but not
> @class=url? The use case being when I don't regard my /about page
> as being a relevant URL for inclusion in my hCard parsing, but do
> wish to have it followed and parsed as the authoritative version.

Not sure whether this is straying into the 20% part of the problem
space? Just my initial response, with little real thought ;-)

john
_______________________________________________
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss



--
Chris Messina
Citizen Provocateur &
 Open Source Ambassador-at-Large
Work: http://citizenagency.com
Blog: http://factoryjoe.com/blog
Cell: 412 225-1051
Skype: 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

Reply via email to