[uf-discuss] The need for a Trackback microformat?
Charles Iliya Krempeaux
supercanadian at gmail.com
Sat Dec 3 13:51:50 PST 2005
On 12/3/05, Chris Messina <chris.messina at gmail.com> wrote:
> On 12/2/05, Ryan King <ryan at technorati.com> wrote:
> > > Enclosures have a different meaning. They are best compared to
> > > attachments in e-mail. The enclosure is a part of the current
> > > document and document+enclosure(s) should be seen as a whole. This
> > > has great value when talking about blog posts (and hAtom) because
> > > attachments are usually connected to a part of the page (a single
> > > blog entry).
> > >
> > > I don't care where I point my profiles to, but rel-enclosure isn't
> > > what I mean when I use rel="enclosure".
> > I don't think your relEnclosure and http://microformats.org/wiki/rel-
> > enclosure are that different, they're just explained differently.
> > Also, I think they're close enough to be resolved. You want to work
> > on that?
> Perhaps rel-enclosure doesn't actually make sense long term. Given
> that relEnclosure, AFAIK, was grafted onto RSS to allow for media
> being "attached" to feeds, rel-enclosure doesn't make sense in your
> regular browser-consumed webpages because we've got <embed> and
> <object>. If RSS had been able to support inline rich media, wouldn't
> those tags have sufficed?
No. In RSS, enclosures instruct the client to pre-download the media,
(but says nothing about "playing" it). Both <embed> and <object> say
"play" the media (and say nothing about pre-downloading it AFAIK).
To me, there are 2 orthogonal concepts here. One is pre-downloading
it. And the other is "playing" it.
It was my (perhaps naive) understanding that rel-enclosure was an
attempt to add pre-downloading to HTML.
> It also seems that relEnclosure was about behavior on the client side
> and less about semantics.
> Let's presume for a minute that we've got infinite bandwidth
If that was the case, then, you would NOT need RSS enclosures.
> infinite storage. In such a world, all embedded media (and hrefs)
> would be able to be pulled in and cached automagically. In which case
> the need for delayed media downloading would be much less, so even if
> you're syncing your 8,000 feeds, which all contain rich media like
> podcasts and vcasts, you would theoretically be able to pull all that
> data down anyway for later consumption.
> So the question is, what is the most effective way to link to that
> media? Indeed, will the media itself supplant the textual content of
> the feed?
With RSS, this whole topic has been very problematic. (And you'll
probably get people arguing alot about it.)
For RSS, enclosures actually say pre-download this. However, the spec
never said "what" to display when you had various combinations of the
RSS <title>, <description>, and <enclosure> elements.
For the systems I've developed I've taken a different approach. What
I've done is started using Atomic RSS:
(Atomic RSS is a mix or RSS and Atom.) The point of this was so that
the RSS <description> element can be replaced by the Atom <summary>
and <content> elements.
(The RSS <description> element is very very broken. Basically, you
don't know the "type" of the data it contains or how it is encoded!)
Using the Atom <content> element, I include SMIL data that tells the
user-agent how to "play" things. Now, it is true that SMIL does
contain it's own technologies to "pre-download" things. However, I've
only used certain modules of SMIL, thus trying to keep things as
simple as possible for clients. And kepts to RSS facilities for
pre-downloading things. This also has the nice effect of keeping
backward-compatability with client's that don't understand Atomic RSS
or that don't understand SMIL.
> Will feeds simply become the distribution method for rich
> media or eventually get into a TV-for-the-web model where you pick
> people to subscribe to and can "tune in" to an aggregate stream of
> them whenever you like? I dunno, and I suppose I'm getting a little
> off topic here.
That's one of the models of content distribution for this. (There's others.)
> So here's what I'm thinking when it comes down to it (now that you
> know what I'm looking at in the future)... Shouldn't relEnclosures
> just be converted to <object> or <embed> tags when they're pulled into
I'd say no.
> Isn't that what the original intention (and indeed, behavior)
> actually implies?
Again, no. RSS enclosures say "pre-download this", not "play this".
> Wasn't the original problem one of embedding rich
> media in RSS and so therefore, relEnclosure is actually made obsolete
> when ported to the world of XHTML microformats?
> Anyway, sorry to go on and on, must be the Parisien air. ;)
I do alot of stuff on this topic, so I'm always happy to discuss it.
Charles Iliya Krempeaux, B.Sc.
charles @ reptile.ca
supercanadian @ gmail.com
developer weblog: http://ChangeLog.ca/
Never forget where you came from
More information about the microformats-discuss