[uf-discuss] hAtom and blog-post-* need some more work
benjamincarlyle at optusnet.com.au
Sat Dec 31 14:39:00 PST 2005
On Sat, 2005-12-31 at 09:20 -0800, Tantek Çelik wrote:
> Though I definitely understand (and applaud) the eagerness to get an hAtom
> format defined, things have definitely been rushed a bit, and there are
> holes in the background research necessary to do a good job. Holes which, if
> they were filled, would most likely result in quite a few changes to the
> hAtom proposal.
The way I interpret this statement in the light of various irc
conversations you and I have been involved in is that hAtom turning the
corner onto a home straight. David has put in a great effort to get
hAtom to a stage where it meets two major design goals. It has a 1:1
correspondance to atom where elements are defined, and it is both
implementable and implemented. hAtom2Atom.xsl exists as the seed of a
reference implementation and now carries with it a growing test suite
too. hAtom is being tested both from the publisher and the subscriber
Several specific issues are currently open on hAtom and are recorded at
the hatom-issues microformats page. Nomenclature is a broad area that
has lacked some definition in the current set of email exchanges. I
suggest that anyone with specific nomenclature issues bring them forward
for resolution. I think that now is the time to get involved to search
out these issues and all other outstanding issues to ensure hAtom makes
it through the gate with the blessing of all and without reservations
Email has a way of keeping frictions from being resolved, and that is
why I usually recommend the use of a more immediate medium such as IRC
for this kind of technical discussion. I think everyone here is more or
less on the same page. I think that once specific technical issues are
identified and discussed that the closeness of any relative positions
will be underscored.
> 1. The formats page has yet to describe "basic structure of an RSS
> document". This is a glaring hole. Given how much more established RSS 2.0
> is over Atom in the space of "syndication", it needs to be taken a lot more
> seriously than that.
> 2. The formats page omits another old "blog post" standard - VJOURNAL. I
> believe Outlook supports VJOURNAL, and if so, greatly outnumbers all RSS
> readers combined. I've at least added a starter section for VJOURNAL:
I have tried to plug this gap. My brain is a little bit sushi'd out from
parsing standards documentation so there is bound to be a fair bit of
detail that is off the mark. Anyone who wants to build on the skeletons
that are now in place is welcome to, as they are welcome to refine them.
RSS is particularly difficult to get a grasp on due to it not really
defining anything. For the most part it seems to assume you know RSS and
how often elements are allowed to be repeated, so just lists out the
Tantek, your focus on VJOURNAL is interesting. It is via our discussion
on #microformats that I learned your interest is inspired by the
existing hCalendar and hCard microformats. VJOURNAL is an IETF standard
built into the same rfc as hCalendar uses as its source. Your suggestion
that this could be a useful source of nomenclature is an interesting
one. Although this format has likely never been used for blogging, it
does contain elements equivalent to significant subset to those of an
atom entry. I see the following possible equivalences:
atom:id = VJOURNAL:UID? Maybe VJOURNAL:URL?
atom:title = VJOURNAL:SUMMARY
atom:updated = VJOURNAL:LAST-MODIFIED
atom:author = VJOURNAL:ATTENDEE? Maybe ORGANIZER?
atom:content = VJOURNAL:DESCRIPTION
atom:link = VJOURNAL:URL?
atom:summary = ?
atom:category = VJOURNAL:CATEGORIES
atom:contributor = VJOURNAL:ATTENDEE?
atom:published = VJOURNAL:DTSTART? Maybe VJOURNAL:CREATED?
atom:source = ?
atom:rights = ?
This summary may be useful for enlightening the unenlightened, however
it is probably not useful progress on hAtom in and of itself. We should
be focusing on specific issues. This list supports the suggestion that
atom:title be called "summary" in the microformat, however it does not
guve us an answer for atom:summary. RSS is similarly blank on the issue,
providing a description element but no summary except for its title.
Atom appears to be the origin of this separation of title and summary,
and this hallmark is something I would suggest that atom boosters would
prefer to keep in place.
So, should we call atom:title "summary"? If so, what should we call
atom:summary? Do any other sources of established terminology exist? Is
this the only real nomenclature issue, or are there more specific issues
waiting in the wings? I suggest taking this opportunity to pick on every
specific item you are not comfortable with and get it out in the open.
General issues without clear focus need to be refined and sharpened
until they are ready to be put onto hAtom-issues, and that should happen
as soon as possible.
Benjamin Carlyle <benjamincarlyle at optusnet.com.au>
More information about the microformats-discuss