[uf-new] Re: Comment Questions

[David Janes]

On Sun, Nov 16, 2008 at 11:38 AM, Martin McEvoy
<martin at weborganics.co.uk> wrote:
> David Janes wrote:
>>
>> On Sun, Nov 16, 2008 at 6:06 AM, Toby A Inkster <mail at tobyinkster.co.uk>
>> wrote:
>>
>>
>>>
>>> #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.)
>>>
>>
>> "hfeed comments" has been kicking around since February, off list, and
>> I got the photos to prove it ;-)
>>
>> I'm not sure why you think #3 forces a particular layout. Let me state
>> more formally:
>>
>> * if Entry "B" is in an Entry Comments element of Entry "A", then
>> Entry "B" is a comment on Entry "A"
>> * an Entry Comments element is identified by using both class names
>> "hfeed comments"
>>
>> That's it: you've got 100% coverage of all examples with no
>> presentation change and no required or implied changes to format
>> needed.
>>
>
> David, you are asserting that all comments are grouped in some way, for this
> you should use xoxo  this will give you the implied structure of a comment
> list, a fair amount of the examples do imply structure and grouping in this
> way by using <ul>, <ol> <dl>,

Did you actually go quantify this?: _Maybe that is how it should be
done_. Since there's no analysis of the examples except how it will
justify rel="in-reply-to", we don't know.

> "hfeed comments"  is simply wrong because you are implying that "hfeed" is
> required? if that's not true you are saying you can  just use "comments"
> does this mean that hfeed is Implied? if that's the case then what is the
> point of using "hfeed" at all? , lastly all of  this doesn't address a
> comment, it only addresses the grouping of comments not the comment this
> discussion does not go there (remember?).

I don't even know where to start addressing this paragraph: it doesn't
seem to correspond to anything I've written. In _every single example
shown comments appear grouped togther_. The argument being made is "we
get to ignore this because then rel="in-reply-to" looks kinda
pointless"

>
> as for all the assertions you, and others are making "that a comment should
> be marked up in hatom" is also wrong because certain basic requirements of
> hAtom do not exist in a comment, an entry-title and a bookmarkable point
> (only 40% have a permalink), comments made on other things (not blogs) very
> rarely have a permalink also saying if an entry-title is not present "make
> something up" is false semantics, you are saying that something exists when
> it quite clearly doesn't

hAtom has very clear rules for how things get "made up": that's the
difference between a physical and logical model. "Making titles up" is
__exactly what happens in the real world on Atom feeds in the real
world corresponding to comments__. It might be inconvenient or ugly or
"oh god" but _that's how people do it_.

> I tried to get the conversation about a comment going again because it
> really is a simple format to build and couldn't understand why a comment
> format hasn't been addressed yet,  now I know why, because some people don't
> understand what the problem is and have preconceptions of how this should be
> solved, which should be the simplest way, which is not dumping the whole
> hAtom format on it, what If I don't want to use hAtom to mark up  a comment?
> I haven't got much choice have I?

If you want to mark up comments with microformats, using microformats
is your only choice. If you want to use microformats, then you have to
use the process, i.e. in particular:

- actually look how comments are being done
- look at how existing microformats can fit the the solution

The proposed rel="in-reply-to" solution that requires 60% of comment
makers to change _presentation_, requires the other 40% to add
semantically incorrect markup (which BTW no rel="in-reply-to"
proponents have bother to address yet) and ignores all the existing
microformats work so far.

-- 
David Janes
Mercenary Programmer
http://code.davidjanes.com