[uf-discuss] The need for a Trackback microformat?

Sat Dec 3 13:51:50 PST 2005

Hello,

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.

> and
> 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:
http://www.tbray.org/ongoing/When/200x/2005/07/27/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
> xhtml?

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.

See ya

--
    Charles Iliya Krempeaux, B.Sc.

    charles @ reptile.ca
    supercanadian @ gmail.com

    developer weblog: http://ChangeLog.ca/
___________________________________________________________________________
 Never forget where you came from