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
_______________________________________________
microformats-discuss mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-discuss
