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:[EMAIL PROTECTED]>
<http://tobyinkster.co.uk>
_______________________________________________
microformats-new mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-new
