[uf-discuss] hAtom draft - class="title"

[David Janes -- BlogMatrix]

Kevin Marks wrote:
> 
> On Dec 27, 2005, at 3:43 PM, Tantek Çelik wrote:
>> This means working deliberately to avoid the two cardinal sins that
>> namespaces typical both enable and encourage:
>>
>> 1. The same term is used to mean two different things
>> 2. Two terms are used to mean the same things
> 
> Indeed. In fact this is one of the advantages of Atom over RSS - 
> resolving ambiguous usage.
> 
> In RSS 'description' is used for both summary and full-content feeds.
> 
> Atom defines distinct 'summary' and 'content' elements for this
> 
> In RSS 'link' is used for both 'entry permalink' and 'external linked 
> element from a brief entry'.
> 
>>
>> The current "established" microformats have avoided this problem by
>> essentially reusing from earlier microformats when possible, *before*
>> reusing from other standards.
>>
>> E.g. hReview has reused a lot from hCard and hCalendar.
>>
>> See http://microformats.org/wiki/existing-classes for an overview.
>>
>> In the case of 'title', Paul is right.  hCard (by way of vCard) has 
>> defined
>> 'title' to mean something in particular.
>>
>> In the case of hReview, we used 'summary' from hCalendar to serve this
>> purpose.
>>
>> Would it be possible to do so for hAtom as well?
> 
> I would say that letting hCard use a bare 'title' to mean 'honorific 
> form of address' was possibly a mistake in retrospect, but it is 
> established.
> 
> That said, 'title' is context-defined in Atom - it can mean 'feed title' 
> or 'entry title'.
> 
> Replacing this with 'summary' would be a mistake, as that needlessly 
> blurs the summary/content distinction which is important for authors, 
> readers and parsers alike.
> 
> I think keeping 'summary' and 'content' are good. hReview's and 
> hCalendar's 'summary' is IMO not really a title in the atom/rss sense, 
> but a one-line abbreviated form.
> 
> So I would suggest 'entry-title'.

Hi Kevin,

(1)
There'll still be a dual use for the name "summary", so we really have 
to establish whether this is going to be kosher or not. I'm cool if it's 
not ... if it's an enumerated design goal of the microformats community.

 From my POV, this is the only major sticking point to making a change 
(or not) is this point.

(2)
'entry-title' is cool with me, but my feeling was that this is 
explicitly resolved by context; that is, "title" appearing within a 
"entry" is an EntryTitle, whereas "title" appearing within a "feed" but 
not within an "entry" is a FeedTitle. This is fairly easy to resolve in 
an XPath sense and using DOM manipulation as I do in Python, and is the 
same rule Atom uses.

(3)
Note that opacity is the only real way to stop meaning conflicts in a 
meaning sense. For example, what if someone included a hCalendar object 
within a hReview ... "I saw this concert and this is what I thought of 
it, here's the schedule for the other nights the band is playing in 
town"? We'll still have multiple "summary" elements floating about.

(4)
Happy New Years everyone! I'm off to party. And jeez, Benjamin, 
shouldn't you be in bed by now? Unless you're not where your extension 
says you are!

Regards, etc...
David