I have some more info on ttl usage now. I haven't tested every aggregator in
my collection, but I've at least done all the ones currently listed in the
profile (except for MyYahoo! which can't subscribe to anything at my
domain). I figure this should be enough to clarify the situation.
For anyone that wants to double check my results, these are the test feeds I
used:
http://216.93.169.119/tests/rss/refresh/default.rsshttp://216.93.169.119/tests/rss/refresh/ttl15.rsshttp://216.93.169.119/tests/rss/refresh/ttl150.rss
The first one is just a baseline test with no ttl to check the default
refresh time. The second has a ttl of 15 to test whether aggregators would
treat the ttl as the minimum refresh frequency. The last one has a ttl of
150 to test whether aggregators would treat the ttl as the maximum refresh
frequency.
For the tests to work the aggregator's default refresh frequency needs to be
greater than 15 and less than 150. For most this isn't a problem, but
Internet Explorer uses 24 hours by default, Opera and Googler Reader use 3
hours, and JetBrains Omea uses 4 hours. For IE and Omea I set the default
refresh time to 60 before testing. For Opera I set the individual refresh
times for each feed as I subscribed. For Google Reader I used a special test
feed with a ttl of 210 (same as the urls above - just change the number on
the end).
All of the following aggregators appeared to ignore ttl completely. In other
words, all feeds refreshed at the same default frequency.
BlogBridge 4.0.1
Bloglines 2007-05-31
Firefox 2.0.0.3
Google Reader 2007-05-31
JetBrains Omea Reader 2.2
NewsGator Online 2007-05-31
RSSBandit 1.5.0.10
The next lot of aggregators appeared to treat ttl as the maximum refresh
frequency. The ttl150 feed would refresh every 150 minutes (180 in some
cases, but never more frequently than 150). The ttl15 feed refreshed at the
default frequency.
BottomFeeder 4.2
CITA RSS Aggregator 2.6
GreatNews 1.0.0.382
IE 7.0.5730.11
NewzCrawler 1.8.0
Opera 9.02 (8585)
Snarfer 0.8.0
The odd one out was FeedDemon (both version 2.1.0.10 and 2.5.0.10), which
basically treated ttl as a recommended rate. When you subscribe to a feed,
FeedDemon will set the refresh rate for that feed to the current ttl. So the
ttl150 feed's initial refresh rate was set to 150 minutes; the ttl15 rate
was set to 15. Those values could be overridden though - they didn't
actually limit the refresh rate in any way.
It's also worth noting that the ttl15 feed only actually refreshed every 30
minutes, despite being set to 15. I'm not sure if that is a limit of the
FeedDemon trial version, a bug, or there's some other reason for it.
Some other things you should know if you want to run these tests yourself.
GreatNews will sometimes force a refresh just by clicking on a feed to view
the results, so it's best to leave it alone for a day while the results
accumulate. Some aggregators (especially the online ones) will behave
unpredictably for the first refresh or two - sometimes they'll refresh
sooner than expected, sometimes later. Once again, it's best to leave them
for a day and let the results accumulate.
The tests rely on an aggregator supporting etags, or archiving results so
you can see a history of all the refreshes that have happened. There are
some that can do neither. These tests won't work very well for such
aggregators.
Bottom line: it seems most aggregators either ignore ttl or treat it as the
maximum refresh frequency (i.e. the aggregator won't refresh more often than
specified). We have one aggregator that is known to treat ttl as a
recommended refresh frequency. We still do not know of any that treat it as
a minimum refresh frequency.
Regards
James
A new draft of the RSS Best-Practices Profile has been published to
incorporate James' TTL testing and my survey of RSS element usage.
http://www.rssboard.org/rss-profile
The biggest issue for debate here is likely to be the new TTL advice
-- check a feed at a frequency equal to its TTL.
We only have three items left on the to-do list.
Changes:
1. Two sentences were added to the Conventions section:
"Tests of TTL support also employed CITA RSS Aggregator 2.6,
NewzCrawler 1.8.0 and Snarfer 0.8.0.
"Some sections of the profile rely on surveys of channel element [1]
and item element [2] usage compiled from 1,933 RSS feeds chosen
because they appear in OPML subscription lists published on the web."
1: http://www.rssboard.org/news/168
2: http://www.rssboard.org/news/169http://www.rssboard.org/rss-profile#conventions
2. Added this sentence to the textInput section:
"Fewer than one percent of surveyed RSS feeds included the textInput
element."
http://www.rssboard.org/rss-profile#element-channel-textinput
3. Revised the skipDays recommendation to the following text:
"Although an aggregator SHOULD NOT request the feed on the days
identified by this element, the point is largely moot because of how
infrequently it is used by publishers. Fewer than one percent of
surveyed feeds included a skipDays element."
http://www.rssboard.org/rss-profile#element-channel-skipdays
4. Added this rating recommendation:
"This element gets little usage among publishers, appearing in fewer
than one percent of surveyed feeds."
http://www.rssboard.org/rss-profile#element-channel-rating
5. Rewrote the TTL section to incorporate James' tests:
http://www.rssboard.org/rss-profile-1-20#element-channel-ttl
This section recommends that aggregators check a feed at a frequency
equal to its TTL. This is a change from previous drafts, which
recommended using TTL as a maximum time to live as intended in the
spec. Because no aggregator has been found that uses TTL as intended,
and there are two contrasting interpretations of what TTL means, this
is the only way to be correct under both interpretations.
6. Three items have been removed from the to-do list without action:
# Add the itunes:* namespace
# Add the sle:* namespace
# Add the mrss:* namespace
None of these is widely supported in current feeds, according to the
survey I just conducted. There are some interop issues with itunes,
because it creates new elements whose purpose is comparable to core
elements, but that issue should wait until the namespace is more
widely adopted.
7. One to-do item has been revised:
# Consider adding dc:date and dc:language
The dc:language element from Dublin Core was the most popular
namespace element to appear in an RSS feed's channel, appearing in 36
percent of the feeds I surveyed.
The core element language is either an RSS language code or a language
code permitted in HTML (in other words, an ISO 639 language code).
http://www.rssboard.org/rss-language-codes
The dc:language element supports ISO 639 plus ISO 3166 codes.
http://dublincore.org/documents/1999/07/02/dces/
"Recommended best practice for the values of the Language element is
defined by RFC 1766 [RFC1766] which includes a two-letter Language
Code (taken from the ISO 639 standard [ISO639]), followed optionally,
by a two-letter Country Code (taken from the ISO 3166 standard
[ISO3166]). For example, 'en' for English, 'fr' for French, or 'en-uk'
for English used in the United Kingdom."
These elements serve the same purpose. Should one be used in
preference to the other? Should the profile tell publishers they
SHOULD NOT include both in a feed?
--- In rss-public@yahoogroups.com, "rcade" <cadenhead@...> wrote:
> The core element language is either an RSS language code or a language
> code permitted in HTML (in other words, an ISO 639 language code).
> The dc:language element supports ISO 639 plus ISO 3166 codes.
This seems to imply that ISO3166 codes are not permitted in <language>.
This is untrue. ISO3166 are valid HTML language codes and thus are also
valid RSS language codes. Or did I miss something here?
> Should one be used in preference to the other?
Definitely! dc:language is redundant (funky).
> Should the profile tell publishers they
> SHOULD NOT include both in a feed?
I would use words like, we RECOMMEND use of <language> over
<dc:language>.
MHO,
Randy Charles Morin
http://www.kbcafe.com
--- In rss-public@yahoogroups.com, "Randy Morin" <randy@...> wrote:
> This seems to imply that ISO3166 codes are not permitted in <language>.
> This is untrue. ISO3166 are valid HTML language codes and thus are also
> valid RSS language codes.
True. I should've included ISO3166 in that reference.
> Definitely! dc:language is redundant (funky).
Anyone have a handle on why it's so common in feeds?
On Tue, Jun 05, 2007 at 10:44:49PM -0000, Randy Morin wrote:
> Definitely! dc:language is redundant (funky).
If dc:language can appear in an item element as well as a channel, that
would be a reason to use it.
-r
Ralpha,
Excellent point.
Rogers,
I didn't see any use of dc:language in the item. Did you check for it?
Thanks,
Randy Charles Morin
http://www.therssweblog.com
--- In rss-public@yahoogroups.com, Ralph Giles <giles@...> wrote:
> If dc:language can appear in an item element as well as a channel,
that
> would be a reason to use it.
>
> -r
>
--- In rss-public@yahoogroups.com, "Randy Morin" <randy@...> wrote:
> I didn't see any use of dc:language in the item. Did you check for it?
Yep. Every element I found is in those reports, with the exception of
some weird invalid stuff like item-body, item-div and their children.
I didn't find any use of item-dc:language.
On Tue, Jun 05, 2007 at 11:48:07PM -0000, rcade wrote:
> Yep. Every element I found is in those reports, with the exception of
> some weird invalid stuff like item-body, item-div and their children.
> I didn't find any use of item-dc:language.
Hmm. Should I start? I needed a way to do this for
http://www.libregraphicsmeeting.org/2007/video.rss
More generally, is there a best practices document
for podcast feeds in particular? I looked at some
examples and they were all wildly different. :)
-r
There isn't a podcast specific best practices documents. The RSS
profile is for both podcast and non-podcast feeds. If someone was
willing to compile a best practices for podcasts, then I'm sure the
advisory board would support it.
Thanks,
Randy Charles Morin
http://www.therssweblog.com
--- In rss-public@yahoogroups.com, Ralph Giles <giles@...> wrote:
> Hmm. Should I start? I needed a way to do this for
> http://www.libregraphicsmeeting.org/2007/video.rss
>
> More generally, is there a best practices document
> for podcast feeds in particular? I looked at some
> examples and they were all wildly different. :)
>
> -r
>
Hey Ralph,
There's a number of things we still need, when it comes podcasts and
vlogs/vodcasts.
Like, how do you tell if an RSS feed contains text, video, or audio
(without actually looking inside.)
Whether is be to use a media="tv" on the HTML <link> element for
video. And media="radio" on the HTML <link> element for audio.
http://maketelevision.com/log/rss_and_atom_feed_auto-discovery_for_internet_tv
Or to use a Content Type parameter. As in
type="application/rss+xml;disposition-type=moving-image", etc.
http://changelog.ca/log/2005/08/21/rss-disposition-hinting-proposal
Or even the use of the MIME types "video/rss+xml" and "audio/rss+xml".
Also need a good way put have playlists inside of feeds. (Probably an
XML namespace extension would be appropriate for those.)
Although, without a format in use for playlists... a "best practices"
document probably isn't the best place for that.
--
Charles Iliya Krempeaux, B.Sc. <http://ChangeLog.ca/>
All the Vlogging News on One Page
http://vlograzor.com/
On 6/5/07, Ralph Giles <giles@...> wrote:
>
> On Tue, Jun 05, 2007 at 11:48:07PM -0000, rcade wrote:
>
> > Yep. Every element I found is in those reports, with the exception of
> > some weird invalid stuff like item-body, item-div and their children.
> > I didn't find any use of item-dc:language.
>
> Hmm. Should I start? I needed a way to do this for
> http://www.libregraphicsmeeting.org/2007/video.rss
>
> More generally, is there a best practices document
> for podcast feeds in particular? I looked at some
> examples and they were all wildly different. :)
Hi Charles!
On Tue, Jun 05, 2007 at 05:25:13PM -0700, Charles Iliya Krempeaux wrote:
> There's a number of things we still need, when it comes podcasts and
> vlogs/vodcasts.
>
> Like, how do you tell if an RSS feed contains text, video, or audio
> (without actually looking inside.)
It's still hard even after you've looked inside!
> http://changelog.ca/log/2005/08/21/rss-disposition-hinting-proposal
> Or even the use of the MIME types "video/rss+xml" and "audio/rss+xml".
We pushed your media-hinting proposal for application/ogg for a while,
and quite liked it internally, but consensus now is to give up and
register video/ogg, audio/ogg, etc. like was done for MPEG. The plan
is at http://wiki.xiph.org/index.php/MIME_Types_and_File_Extensions
If you'd like to offer your comments, I'd appreciate it.
> Also need a good way put have playlists inside of feeds. (Probably an
> XML namespace extension would be appropriate for those.)
You might look at xspf.org if you want an xml playlist namespace.
> Although, without a format in use for playlists... a "best practices"
> document probably isn't the best place for that.
Yahoo's Media RSS also lets you do playlists as well as (perhaps
more importantly) alternate versions of the same resource. I take
it this namespace hasn't seem much adoption by aggregators?
-r
Maybe I didn't understand, but why do you need to know if an RSS feed
contains text, video or audio without actually looking inside?
Thanks and confused,
Randy Charles Morin
http://www.therssweblog.com
--- In rss-public@yahoogroups.com, "Charles Iliya Krempeaux"
<supercanadian@...> wrote:
>
> Hey Ralph,
>
> There's a number of things we still need, when it comes podcasts and
> vlogs/vodcasts.
>
> Like, how do you tell if an RSS feed contains text, video, or audio
> (without actually looking inside.)
>
> Whether is be to use a media="tv" on the HTML <link> element for
> video. And media="radio" on the HTML <link> element for audio.
>
> Like, how do you tell if an RSS feed contains text, video, or audio
> (without actually looking inside.)
Well, you look at the feed contents. The feed itself doesn't contain
anything. It contains links to other things that may or may not be media
types. You can't really overload the semantics of an HTML href with this
sort of thing.
The proposal to revise the RSS specification has passed 5-1 with RSS
Advisory Board members Matthew Bookspan, Rogers Cadenhead, Christopher
Finke, Randy Charles Morin and Paul Querna voting in favor, Eric Lunt
voting against and members James Holderness, Meg Hourihan, Jenny
Levine and Jason Shellen abstaining.
The Extending RSS section of the specification has been clarified with
the addition of the words "and attributes" twice in the following
sentence:
"A RSS feed may contain elements and attributes not described on this
page, only if those elements and attributes are defined in a namespace."
No other changes were made. All edits to the specification are logged.
This revision of the document has the version number 2.0.9.
http://www.rssboard.org/news/171
On Wed, Jun 06, 2007 at 01:55:17PM -0000, Randy Morin wrote:
> Maybe I didn't understand, but why do you need to know if an RSS feed
> contains text, video or audio without actually looking inside?
If you look at the blog post Charles linked, it's about automated feed
discovery. So the idea is to sort feed urls to the appropriate
aggregator based on <link rel=""> in an html page without having
to download and parse the feed itself.
Does that address your confusion?
-r
I understand the use case, but I don't understand what is preventing
you from downloading the RSS file.
Thanks,
Randy Charles Morin
http://www.therssweblog.com
--- In rss-public@yahoogroups.com, Ralph Giles <giles@...> wrote:
> If you look at the blog post Charles linked, it's about automated
feed
> discovery. So the idea is to sort feed urls to the appropriate
> aggregator based on <link rel=""> in an html page without having
> to download and parse the feed itself.
>
> Does that address your confusion?
>
> -r
>
Given the fact that RSS is all about automation and that <link> tag editing
is, shall we say, inconsistent at best, it seems a little bit much to expect
this to be anything remotely approaching a workable solution.
I've long been a champion for making thing simple, but there are limits.
There's really nothing about how RSS feeds are used that gives any real hope
of there being a consistent way to discover what the feed references. What
a feed has 'today' might be entirely different than what it was tomorrow (or
even an hour from now). That and the HTML pages for them aren't necessarily
edited using the same interfaces. You'd basically be asking for whatever's
creating the content to put a reference of some kind as to what the target
HTML web page "contains". Since that's how most feeds are created, culled
as an index of web pages. Yes, you "could" do this but I don't see many
tools or websites going this extra mile. It's challenging enough just
getting them to do feeds properly...
And then there's the whole can of worms dealing with browser 'presentation'
alternatives. Oy, it's a real mess.
-Bill Kearney
Sydnic8.com
> On Wed, Jun 06, 2007 at 01:55:17PM -0000, Randy Morin wrote:
>
> > Maybe I didn't understand, but why do you need to know if an RSS feed
> > contains text, video or audio without actually looking inside?
>
> If you look at the blog post Charles linked, it's about automated feed
> discovery. So the idea is to sort feed urls to the appropriate
> aggregator based on <link rel=""> in an html page without having
> to download and parse the feed itself.
>
> Does that address your confusion?
Here's what RSS 2.0 feeds are putting into dc:language, from a run of
909 feeds I checked this morning:
da-dk 1
de 2
de-AT 1
de-DE 2
en 338
en-AU 5
en-CA 4
en-GB 8
en-NZ 2
en-US 529
eng 1
es-ES 3
fa-IR 1
fr-FR 2
ja-JP 1
nl 2
pt 1
pt-BR 1
pt-PT 3
sv-SE 1
zh-CN 1
Aside from "eng", which is probably a mistake, I think these are all
acceptable values in channel-language, so the publishers could adopt
the core element and achieve the same results.
Skimming the generator tags for some of these feeds, I found a lot
from three programs: CommunityServer 2.1 SP1, CommunityServer 2007 SP1
(Build: 20510.895) and Dottext 0.94. I'll send an email to these
programmers to let them know about this discussion.
On Wed, Jun 06, 2007 at 04:11:09PM -0000, Randy Morin wrote:
> I understand the use case, but I don't understand what is preventing
> you from downloading the RSS file.
There are two issues.
One is that it's an optimization. The same reason the enclosure element
has type and length attributes when nothis is preventing you from doing
a header request on the files.
The other is that it can be hard to tell even when looking inside. Some
enclosure types are ambiguous, and as Bill Kearney said, a feed can
contain one thing one day, something else entirely the next. So it might
be nice if authors could be specific.
Off topic, but perhaps a useful analogy, we ran into this with the Ogg
format. We thought we could force a solution to poor handling of
containers by the media-type mechanism, and I think we (...eventually...)
did in disposition hinting proposal and the codec hinting documented in
RFC 4281.
So we registered only one mime-type, application/ogg, and recommended
only one extension .ogg. But the users we hear from all the time want
to distinguish between "audio" and "video" files, and dispatch them
to distinct players, based on the filename extension. Not on file
metadata, and not on content sniffing. We had five years of flame wars
on the topic before giving up on the strategy.
This may be another case where worse is better.
-r
> There are two issues.
>
> One is that it's an optimization.
I certainly support the notion of being stingy with network requests. The
trouble is given the vast array of content being published via feeds it
seems unlikely that this degree of optimization would turn out to be useful
on a wide enough scale. Make things as simple as possible, but no simpler.
> The same reason the enclosure element
> has type and length attributes when nothis is preventing you from doing
> a header request on the files.
This is different. For an enclosure you're talking about providing hints
for what would generally be a single chunk of content. Should a mechanism
be jammed into it to allow defining the sub-content if the enclosure is a
playlist? Or even if it's another RSS feed? At what point is the hinting
too much?
I think the crux of my objection is the attempt to define an entire instance
of a 'feed' as being solely of one content type. I reject that notion
completely. I can understand why some folks might want to do this, I don't
think I support the idea. I could, perhaps, be swayed with more effective
examples.
The trouble is crappy tools like iTunes fail to support the full range of a
feed's content. As in, only playing the audio, not showing the text.
Leading to folks trying to publish feeds with content solely for the audio
or video device instead of just publishing one feed. The enclosure URI and
metadata are small enough as to be trivial. Or likewise the text content
being ignored.
We could go off on a whole other tangent regarding accept headers during
HTTP requests... Those would be better served as a means to "optimize" a
feed based on the retrieving end's ability/desire to consume content types.
But here again I sense over-optimization, and the unlikelihood of any
serious uptake in the field.
> The other is that it can be hard to tell even when looking inside. Some
> enclosure types are ambiguous, and as Bill Kearney said, a feed can
> contain one thing one day, something else entirely the next. So it might
> be nice if authors could be specific.
To what end? This introduces a per-instance level of labelling that's
currently NOT part of how RSS feeds are expected to be consumed.
It's not that I don't sympathize with the idea of being able to automate
content consumption, I do. I'm just not sure this is the way to do it.
Various "when all you have is a hammer..." analogies seem applicable here.
But I do support more accurate content type indicators on an <enclosure>
element. That should be 'enough' to let an automation tool do a better job
of analyzing the suitability of the feed.
> Off topic, but perhaps a useful analogy, we ran into this with the Ogg
> format. We thought we could force a solution to poor handling of
> containers by the media-type mechanism, and I think we (...eventually...)
> did in disposition hinting proposal and the codec hinting documented in
> RFC 4281.
I'm unfamiliar with the ogg situation but grasp the problem you're
presenting.
> So we registered only one mime-type, application/ogg, and recommended
> only one extension .ogg. But the users we hear from all the time want
> to distinguish between "audio" and "video" files, and dispatch them
> to distinct players, based on the filename extension. Not on file
> metadata, and not on content sniffing. We had five years of flame wars
> on the topic before giving up on the strategy.
Well, just because one format dug itself a grave doesn't mean another should
join it. Heh.
> This may be another case where worse is better.
Which being worse?
-Bill Kearney
I suspect you'll have 5 more years of flame wars and still no solution
down this path. Your best bet is to create a solution that works within
the given parameters.
Thanks,
Randy Charles Morin
http://www.therssweblog.com
--- In rss-public@yahoogroups.com, Ralph Giles <giles@...> wrote:
> We had five years of flame wars
> on the topic before giving up on the strategy.
Hey Ralph,
On 6/5/07, Ralph Giles <giles@...> wrote:
>
> Hi Charles!
>
> On Tue, Jun 05, 2007 at 05:25:13PM -0700, Charles Iliya Krempeaux wrote:
>
> > There's a number of things we still need, when it comes podcasts and
> > vlogs/vodcasts.
> >
> > Like, how do you tell if an RSS feed contains text, video, or audio
> > (without actually looking inside.)
>
> It's still hard even after you've looked inside!
>
> > http://changelog.ca/log/2005/08/21/rss-disposition-hinting-proposal
> > Or even the use of the MIME types "video/rss+xml" and "audio/rss+xml".
>
> We pushed your media-hinting proposal for application/ogg for a while,
> and quite liked it internally, but consensus now is to give up and
> register video/ogg, audio/ogg, etc. like was done for MPEG. The plan
> is at http://wiki.xiph.org/index.php/MIME_Types_and_File_Extensions
> If you'd like to offer your comments, I'd appreciate it.
(Group... please excuse the non-RSS stuff here... RSS stuff follows
this comment block... later on in this e-mail.)
== .flac
I noticed that that most the extensions (you have there) are 3 letter
codes (like .ogx, .oga, .ogv). All except for one that is -- all
except for: .flac
Sometimes people choose to only use 3 letter codes for 8.3
compatibility. (I.e., to work with the limitations of the old DOS
file naming system that only allowed a 3 letter codes for the
extension.)
Were you going for DOS 8.3 compatibility? And if so, wouldn't that
warrant making .flac a 3 letter code too? (Maybe something like
.flc?) (If not then ignore that comment.)
== text/cmml
Long story short... I'd suggest changing the CMML MIME type to
"application/cmml+xml". Here's the long story though....
(As I remember) people switched the XML MIME type from "text/xml" to
"application/xml" because of things called "text transcoders". (These
"text transcoders" were causing XML files to become corrupted. The
things is... what these text transcoders were doing was correct. XML
was doing the "wrong" thing.)
Apparently, in certain places (like Japan I think), it is common to
have these "invisible" text transcoders translate anything with a
"text/*" MIME type into the their native character set.
This transcoding assumes the original document's encoding is 7-bit ASCII.
This is a problem for XML because the default character set is UTF-8.
And, you can switch the character set within the XML file with the
"<?xml ...?>" header. (And through some other methods too.)
This directly conflicts with the "text/*" MIME types. (Assuming I
remember correctly...) all "text/*" MIME types are 7-bit ASCII.
(I.e., software is free to discard or ignore the 8th bit!!! And that
can corrupt things.)
This was also the motivation for people to want to give RSS the MIME
type "application/rss+xml"
== application/flac
Shouldn't this be "audio/flac"?
> > Also need a good way put have playlists inside of feeds. (Probably an
> > XML namespace extension would be appropriate for those.)
>
> You might look at xspf.org if you want an xml playlist namespace.
I was. I was even talking to Lucas Gonze about it. (I can't find his
original [private] e-mail where he said it, but...) I think his
recommendation was to use/create a new XML format, because there were
certain requirements that XSPF didn't cover.
> > Although, without a format in use for playlists... a "best practices"
> > document probably isn't the best place for that.
>
> Yahoo's Media RSS also lets you do playlists as well as (perhaps
> more importantly) alternate versions of the same resource. I take
> it this namespace hasn't seem much adoption by aggregators?
I don't believe Media RSS let's you do playlists.
(And by playlist, I mean something where it lets you say stuff like...
play this video first, and then this video, and then this video, etc
etc....)
But... Media RSS is a really nice format though. There's alot of good
stuff in there.
--
Charles Iliya Krempeaux, B.Sc. <http://ChangeLog.ca/>
All the Vlogging News on One Page
http://vlograzor.com/
XSS restrictions are often preventing you from downloading the RSS
feed. (Like with in-page JavaScrit and bookmarklets.)
--
Charles Iliya Krempeaux, B.Sc. <http://ChangeLog.ca/>
All the Vlogging News on One Page
http://vlograzor.com/
On 6/6/07, Randy Morin <randy@...> wrote:
>
> I understand the use case, but I don't understand what is preventing
> you from downloading the RSS file.
> Thanks,
>
> Randy Charles Morin
> http://www.therssweblog.com
>
>
> --- In rss-public@yahoogroups.com, Ralph Giles <giles@...> wrote:
> > If you look at the blog post Charles linked, it's about automated
> feed
> > discovery. So the idea is to sort feed urls to the appropriate
> > aggregator based on <link rel=""> in an html page without having
> > to download and parse the feed itself.
> >
> > Does that address your confusion?
> >
> > -r
Hello Randy,
Also, things like in-page JavaScript will NOT be able to read the
contents of the RSS feed if it is on a different domain. XSS
restrictions prevent that. (Feedburner feeds are a good example of
this.)
Same goes for bookmarklets. (They won't be able to read teh RSS feed
contents either.)
So... having the info in the HTML <link /> element is important.
I.e., you need something like...
<link rel="alternate" type="video/rss+xml" href="/vrss" />
See ya
--
Charles Iliya Krempeaux, B.Sc. <http://ChangeLog.ca/>
All the Vlogging News on One Page
http://vlograzor.com/
On 6/6/07, Ralph Giles <giles@...> wrote:
>
> On Wed, Jun 06, 2007 at 01:55:17PM -0000, Randy Morin wrote:
>
> > Maybe I didn't understand, but why do you need to know if an RSS feed
> > contains text, video or audio without actually looking inside?
>
> If you look at the blog post Charles linked, it's about automated feed
> discovery. So the idea is to sort feed urls to the appropriate
> aggregator based on <link rel=""> in an html page without having
> to download and parse the feed itself.
>
> Does that address your confusion?
>
> -r
You can use Google's AFAX Feed API or write your own feed cache to
access RSS from Javascript.
http://code.google.com/apis/ajaxfeeds/
Hope this helps,
Randy Charles Morin
http://www.therssweblog.com
--- In rss-public@yahoogroups.com, "Charles Iliya Krempeaux"
<supercanadian@...> wrote:
>
> Hello Randy,
>
> Also, things like in-page JavaScript will NOT be able to read the
> contents of the RSS feed if it is on a different domain. XSS
> restrictions prevent that. (Feedburner feeds are a good example of
> this.)
>
> Same goes for bookmarklets. (They won't be able to read teh RSS
feed
> contents either.)
>
> So... having the info in the HTML <link /> element is important.
>
> I.e., you need something like...
>
> <link rel="alternate" type="video/rss+xml" href="/vrss" />
>
>
> See ya
>
> --
> Charles Iliya Krempeaux, B.Sc. <http://ChangeLog.ca/>
>
>
> All the Vlogging News on One Page
> http://vlograzor.com/
>
> On 6/6/07, Ralph Giles <giles@...> wrote:
> >
> > On Wed, Jun 06, 2007 at 01:55:17PM -0000, Randy Morin wrote:
> >
> > > Maybe I didn't understand, but why do you need to know if an
RSS feed
> > > contains text, video or audio without actually looking inside?
> >
> > If you look at the blog post Charles linked, it's about
automated feed
> > discovery. So the idea is to sort feed urls to the appropriate
> > aggregator based on <link rel=""> in an html page without having
> > to download and parse the feed itself.
> >
> > Does that address your confusion?
> >
> > -r
>
On Wed, Jun 06, 2007 at 02:58:51PM -0400, Bill Kearney wrote:
> This is different. For an enclosure you're talking about providing hints
> for what would generally be a single chunk of content. Should a mechanism
> be jammed into it to allow defining the sub-content if the enclosure is a
> playlist? Or even if it's another RSS feed? At what point is the hinting
> too much?
"Containers are hard." ?
> I think the crux of my objection is the attempt to define an entire instance
> of a 'feed' as being solely of one content type. I reject that notion
> completely. I can understand why some folks might want to do this, I don't
> think I support the idea. I could, perhaps, be swayed with more effective
> examples.
I was just explaining what I thought Charles was on about. I
think we have reached the end of my ability to argue for it.
But people do, in fact, treat feeds as being solely of one content type.
The primary interface for a podcast feed is a music player, often a
portable one. The text and link might be useful in deciding what to
listen to, or in getting more information later, but the text is not the
point, because an audio blog is different from a text blog with audio. I
agree that it is good to generate a feed that works well in both a
text-oriented and an audio-oriented client, but creators will also
target their audience.
It's even worse with video, where the assumption of a single codec and
encoding profile is less universal, so we have sites like rocketboom
providing 10 different feeds of the same video content because
negotiation is too hard.
Or http://cbc.ca/quirks/ which links two podcast feeds: one broken
into story segments and one with the entire week's show in a single
item. And the (blog-like) episode pages don't have a feed at all!
Of course, the categorical marks we've been discussing don't help with
any of this. :)
-r
> because negotiation is too hard.
Or because lazy programmers don't take the time to make the eff'ing crap
work right.
It's exceptionally bad design to bend a format or protocol to stoop to the
level of bad tools.
On Wed, Jun 06, 2007 at 12:56:04PM -0700, Charles Iliya Krempeaux wrote:
> == .flac
>
> I noticed that that most the extensions (you have there) are 3 letter
> codes (like .ogx, .oga, .ogv). All except for one that is -- all
> except for: .flac
.flac is already established. Didn't seem breaking the .3 convention for
the rest of the new ones. There was some mumbling about fat filesystems
on flash players. Presumedly one would use .fla or .flc if it's an
issue.
Yes, it should probably be audio/flac. I think the reasoning was that
audio/flac would be a "raw" stream without the native framing, but no
one's looked at doing flac-over-rtp so we don't know how important that
is.
> == text/cmml
>
> Long story short... I'd suggest changing the CMML MIME type to
> "application/cmml+xml". Here's the long story though....
Didn't you tell me at some point that registration of foo/bar+baz media
types was discouraged? That's part of why we went with disposition-type
instead of just audio/ogg+vorbis et al.
> Apparently, in certain places (like Japan I think), it is common to
> have these "invisible" text transcoders translate anything with a
> "text/*" MIME type into the their native character set.
Is this still common practice?
> I was. I was even talking to Lucas Gonze about it. (I can't find his
> original [private] e-mail where he said it, but...) I think his
> recommendation was to use/create a new XML format, because there were
> certain requirements that XSPF didn't cover.
Would be nice to know what those objections were before reinventing the
wheel.
> I don't believe Media RSS let's you do playlists.
The spec says, under <media:content>, "The sequence of these items
implies the order of presentation."
-r
Send Email
