Hello, On 12/3/05, Chris Messina <[EMAIL PROTECTED]> wrote: > On 12/2/05, Ryan King <[EMAIL PROTECTED]> 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 _______________________________________________ microformats-discuss mailing list [email protected] http://microformats.org/mailman/listinfo/microformats-discuss
