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

[Charles Iliya Krempeaux]

Hello,

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)

I'm all for the possibilty of using client side JavaScript, User
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).


See ya

--
    Charles Iliya Krempeaux, B.Sc.

    charles @ reptile.ca
    supercanadian @ gmail.com

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