[uf-new] Re: Comment Questions

[Martin McEvoy]

David Janes wrote:
> 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.
>
>   
The same as your FALSE assertions that all comments are feeds how do you 
assert that? I have not seen a single comment that looks like a feeed

 in-reply-to is the popular approach supported by Sarven, Toby, and 
myself,  the suggested  term is rel="in-reply-to", which I dont like 
just rel="reply" will do, I have also Asserted that rel="reply"  can be 
defined as saying that The "reply" element is used to indicate that an 
entry is a response to another resource.  thats all nothing more....
>> "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"
>   

Infact this whole discussion is kinda pointless dont you think David? 
because You are talking about thing that don't concern a comment

>   
>> 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_.
>
>   

What by marking up a title element in a comment and leaving it empty, or 
putting a note in there saying Make something UP, Is that really how 
people do it? Show me the evidence David (and I dont mean a feed 
example, I mean actual markup of a comment)...


>> 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
>   

I suggest you do the same David
> 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.
>   

So you don't Like rel-reply, Its too complex for you?, Fair enough, but 
at least make a counter proposal that doesn't involve using a 
sledgehammer  to bang in a nail

so far a comment is made up of only 4 properties

    * author (name)100%
    * comment (text) 100%
    * published (date) 100%
    * author-url (href) 92%

How do those four properties fit into the hAtom scheme of things, do you 
see a feed element?

Last thing David you still have not re-formatted your Selected 
examples[1]? to just display information about a comment(like the rest 
of the examples do), would you like me to do it for you?

[1] http://microformats.org/wiki/comment-examples#Selected_Examples


Thanks.

-- 
Martin McEvoy

http://weborganics.co.uk/