[uf-new] Re: Comment Questions

[Toby A Inkster]

So to summarise the discussion so far (and if anyone thinks I've  
missed out an important point here, feel free to step in) it seems  
that there are three basic proposals:

1. A special link from the comment to the thing being commented on.
2. A special link from the comment to itself.
3. Nesting an hfeed of comments within the thing being commented on.

#1 is Sarven's rel="in-reply-to" proposal and variations on that  
theme. Advantages of it are that authors may give links to items  
which are off-page (for example, where a list of comments has been  
paginated due to extreme length), that a single comment may be made  
in-reply-to multiple items, and that it's conceptually very similar  
to Atom's threading extension (RFC 4685). A disadvantage is that it  
requires a link from one comment to another - such links are only  
found on a minority of sites in the wild, and whatsmore, they require  
the thing to which we are linking to have a fragment identifier.

#2 is mostly Martin's proposal. Variations on rel="contact bookmark".  
Advantage of this is that it makes the comment self-contained, and  
does not introduce any new terms into the microformats lexicon.  
Disadvantages are that it again requires a visible link: to the  
comment itself, which is more common than to the thing being  
commented on (as per #1), but still only found in a minority of cases  
in the wild; it stretches the limit of XFN's rel="contact" almost to  
breaking point; it is an unusual use of rel="contact" (it would be  
more normal to place rel="contact" on the author's url); and it  
offers no explicit connection between the comment and the thing being  
commented on.

#3, I think, David first brought to this list, with class="hfeed  
comments", though I had previously proposed class="hfeed replies" to  
Sarven off-list a month or two ago. Advantages are that although an  
explicit connection is given by placing the feed of replies within  
the thing being commented on, it requires no visible link at the  
comment level, and no fragment identifiers are required for each  
comment. This is a big advantage as it closely matches current  
publishing patterns. The disadvantages though are that it only allows  
a comment to be in reply to one particular thing; and it forces  
publishers of threaded messages to use one particular layout (the  
threaded one) rather than, say, a purely chronological order as the  
latter would lose connections between comments. (The threaded layout  
is of course the most common in practice, but in general microformats  
have historically steered away from enforcing any particular layout.)

My proposal yesterday, was to allow both #1 *and* #3. This is because  
#3 is probably the best practical solution and most closely matches  
current publishing patterns, and #1 although less in tune with  
current publishing, mitigates both of #3's disadvantages, its  
advantages slotting nicely into #3's gaps. It is also worth noting  
that the combination of #1 and #3 is very similar to the solution  
that the Atom Publishing Format and Protocol working group arrived at  
with RFC 4685.

-- 
Toby A Inkster
<mailto:mail at tobyinkster.co.uk>
<http://tobyinkster.co.uk>