[uf-discuss] The need for a Trackback microformat?
Charles Iliya Krempeaux
supercanadian at gmail.com
Mon Dec 5 15:50:31 PST 2005
On 12/5/05, Kevin Marks <kmarks at technorati.com> wrote:
> OK, this brings us to the heart of Podcasting. For much discussion, see
> the last two videos with rel="enclosure" on my blog...
> On Dec 3, 2005, at 1:51 PM, Charles Iliya Krempeaux wrote:
> > On 12/3/05, Chris Messina <chris.messina at gmail.com> wrote:
> >> On 12/2/05, Ryan King <ryan at technorati.com> wrote:
> >>> 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?
> Yes, the meaning is the same. If we can revise the wording to make this
> clearer, good.
> >> 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 is for pre-downloading, and also to imply synchronisation to a
> non-browser client. The goal is to enable transparent playback of media
> you subscribe to, with no waiting. In other words, the 'playing new
> stuff to me on my bike ride to work' scenario.
> >> 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?
> The textual content becomes annotation fro the media, in a podcast,
> which has beneficial effects: it is indexable by search engines and
> other tools that can read HTML (instead of having to spelunk thorugh
> giant binary media files looking for metadata)
> >> 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.
> They already are - see DTV
> >> 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.
> No, that's missing the point.
Could you elaborate on this please. (How am I missing the point)
Scripts, or whatever technique to convert the rel-enclosure's to
<object>'s, <embed>'s, or whatever to play it. But, in the actual
HTML code of the page, I think it would better to just the
rel-enclosure'd <a> tag.
To me, this is more of a usability issue.
Now, granted, it would be nice if we could attach more meta data to
the rel-enclosure, to allow for better "playing". (And maybe that
calls for a new Microformat.) But I still think keeping it as a
rel-enclosure'd <a> tag would be better. (It doesn't always make
sense to treat a media file all by itself. Sometimes it is related to
others in a particular way.)
I've been pondering the idea of something like hSMIL for a while. So,
it may be a path than can be taken. Although there are other paths
too (that I've been thinking of).
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