Hi folks--
Didn't get any response before, so just wanted to try one more time:
Is anyone at RssBoard interested in providing an XML namespace for RSS 2.0, for
when RSS elements need to be nested inside other XML? I've seen it mentioned on
this group before.
Having a namespace would allow for the structure and meaning of RSS to be used
inside XML documents other than RSS. See:
http://masonlee.org/2009/09/11/rsscloud-atom-extension/ as an example of one
such use.
Of course, RssBoard.org suggesting a namespace for easier embedding of RSS 2.0
elements would not affect RSS 2.0 in anyway. RSS 2.0 documents would continue
to *require* no namespace.
This seems to me well within the scope of an organization like RSS board.
Cheers,
Mason Lee
http://masonlee.org
Randy Charles Morin and I have been working on draft documentation for an
RSS namespace.
Here's a link to it:
http://www.rssboard.org/rss-namespace
As the docs state, it has not been approved by the board yet and is offered
for discussion purposes only. We'd love to get feedback on it.
If anyone has one or two more examples of how RSS could be used in another
XML dialect, that would be helpful.
[Non-text portions of this message have been removed]
Hey, that's really great!
(Turns out there were many good responses to my earlier post that I missed
because my subscription notifications to this list are not what I thought.
Embarrassing!)
I have some comments regarding the namespace choice:
"http://www.rssboard.org/rss-namespace"
1. The RSS version should probably be included in the namespace URL.
2. The year 2009 perhaps should be included in the namespace URL to mitigate the
fact that ownership of domain names changes hands and URLs may get repurposed.
I think what you want is a namespace that will be globally unique forever--even
if there is no document hosted there in the future. Using the year helps out
future owners of the domain.
Some real-world examples:
http://www.w3.org/2001/XMLSchemahttp://www.w3.org/2005/Atomhttp://xml.apache.org/xmlbeans/2004/02/xbean/config
(Though there are plenty of counter examples!)
For these reasons, I believe a better namespace URL is something like:
http://www.rssboard.org/2009/rss2.0
But at least:
http://www.rssboard.org/rss2.0-namespace
Thanks for all this!
I read the draft at http://www.rssboard.org/rss-namespace and it looks good.
Cheers,
Mason
http://masonlee.org
--- In rss-public@yahoogroups.com, Rogers Cadenhead <cadenhead@...> wrote:
>
> Randy Charles Morin and I have been working on draft documentation for an
> RSS namespace.
> Here's a link to it:
>
> http://www.rssboard.org/rss-namespace
>
> As the docs state, it has not been approved by the board yet and is offered
> for discussion purposes only. We'd love to get feedback on it.
>
> If anyone has one or two more examples of how RSS could be used in another
> XML dialect, that would be helpful.
>
>
> [Non-text portions of this message have been removed]
>
Nate,
Believe it or not, that's just one big weird-ass looking singular link, not
multiple links. There's nothing in RSS about having multiple links in the link
element.
Thanks,
Randy
--- In rss-public@yahoogroups.com, "nrutman" <nathan.rutman@...> wrote:
>
> I'm working on parsing some RSS 2.0 content, and I've found that several
popular RSS 2.0 documents have multiple links embedded in one <link> tag
separated by asterisks.
>
> For instance, this is from the Yahoo Finance feed:
>
>
<link>http://us.rd.yahoo.com/finance/news/rss/story/*http://us.rd.yahoo.com/fina\
nce/news/topnews/*http://biz.yahoo.com/ap/091009/as_india_earns_infosys.html</li\
nk>
>
> Is this part of the RSS 2.0 spec? It doesn't look like it to me. Is this
common? How should I handle this?
>
> Thanks,
> -Nate
>
Hello, everybody. Here are some comments on the draft rss-namespace document
posted at http://www.rssboard.org/rss-namespace
1.) The Introduction says: "This namespace requires the
"http://www.rssboard.org/rss-specification" declaration in the top-level element
of the XML dialect that's making use of RSS..."
I think that's not worded quite right. The XML namespace declarations are
inherited such that any parent node or even the nested rss elements themselves
can declare the namespace. I think it should be sufficient to state the decided
namespace and direct the reader to "http://www.w3.org/TR/REC-xml-names/" for
instructions on how to use it, but here are three examples:
<root xmlns="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6">
<midlevel xmlns:rss="http://www.rssboard.org/rss-namespace">
<rss:rss .../>
</midlevel>
</root>
<root xmlns="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6">
<rss xmlns="xmlns="http://www.rssboard.org/rss-namespace" .../>
</root>
<root xmlns="urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6">
<rss:cloud xmlns:rss="http://www.rssboard.org/rss-namespace" .../>
</root>
2.) I still think the namespace URL should include at least the version "2.0",
as per my last post: http://tech.groups.yahoo.com/group/rss-public/message/1963
3.) If necessary, the motivation for providing a namespace could be explained
with something like the following:
"Because RSS 2.0 has no XML namespace, direct reuse of its XML elements inside
other XML documents can often be difficult and sometimes impossible. Rather than
requiring repeated invention of an ad hoc namespace each time full or partial
embedding of RSS-like data is required, the Rss Advisory Board is here
recommending a common XML namespace [and providing XML schema documents to go
with it?]. It is important to understand that Namespaced RSS 2.0 is not RSS 2.0
compliant, and therefore should only be used in special circumstances, and never
in the regular publication or consumption of RSS 2.0 feeds."
4.) You asked for other examples. I think the "cloud" tag is the best, and you
have that one. One extreme example might be temporarily nesting an entire RSS
document inside another XML doc. For instance, one might like to define a WSDL
function that takes RSS-structured data as parameter. Since trying to embed
non-namespaced XML in something like WSDL can sometimes be problematic (depends
on your tools), the RSS data might normally have to be passed as a string with
all XML being escaped. Unfortunately you then have unstructured data at the
WSDL level, and further, when reconstructed internally as non-namespaced RSS,
the RSS types may cause collisions when considered in a global ontologies. One
possible solution--not always optimal of course--is to first transform the RSS
2.0 XML into "Namespaced RSS 2.0" XML for internal use. If this approach is
taken, transformations to and from the Namespaced RSS 2.0 to the standard
non-namespaced RSS 2.0 would still always be required for interoperability with
the normal RSS world.
5.) I think it would be helpful to provide an XSD for Namespaced RSS 2.0, to
help developers write conforming code. Is there a preferred XSD for RSS 2.0
today that could adapted? I found existing XSD for RSS 2.0 here:
http://weblogs.asp.net/wkriebel/archive/2004/03/07/85642.aspx
Hope this is helpful.
Cheers,
Mason Lee
http://masonlee.org
With the current interest in rssCloud and PubSubHubbub (PuSH), I've been
thinking about all the bandwidth that's consumed by the RSS elements that
describe the feed. When a client requests an RSS feed 14 times in one day, it
gets the basic details of the feed -- title, link, image, ttl and so on -- 14
times even though most of them stay the same for months if not years.
James Holderness directed me to RFC3229+feed, a method to request partial RSS
feeds that omit elements that a client has already seen. Here's information on
that:
http://www.wyman.us/main/2004/09/using_rfc3229_w.html
But as far as I can determine, this approach still sends all of the channel
elements that describe the feed itself. I wanted to float an idea here to see if
mailing list members think it would be useful:
<rssboard:feedDetails>http://ekzemplo.com/feedinfo.rss</rssboard:feedDetails>
This channel-level RSS element identifies a URL that contains the full details
about the feed. The details would be expressed as an RSS feed without any item
elements.
An optional ttl attribute could contain the number of days the publisher would
like clients to cache the information before checking it again:
<rssboard:feedDetails
ttl="30">http://ekzemplo.com/feedinfo.rss</rssboard:feedDetails>
A publisher who wished to make use of this would be advised to move all channel
elements except for title, link, description and atom:link to the detail URL.
Title, link and description are required in RSS, and atom:link identifies the
feed's URL so it can't be moved.
I posted this idea on my blog [1], and Antone Roundy had a better idea than ttl
-- putting the date and time the feed details were last updated in the element,
like this:
<rssboard:feedDetails lastUpdated="Tue, 13 Oct 2009 09:01:25
-0400">http://ekzemplo.com/feedDetails.rss</rssboard:feedDetails>
That way, the client knows when the detail feed needs to be checked for an
update, and never checks it otherwise.
1: http://workbench.cadenhead.org/news/3562
In theory this info is already coming with the feed as part of the HTTP
headers.
Use the data that's already present.
But since that data is often ignored (and sometimes wrong because of poor
scripting) what's to justify making the effort to introduce yet another way
to get it? What evidence exists to prove there would be any uptake of it?
Don't get me wrong, I pitched for much the same notions ages ago. The
market apparently doesn't care enough to manage their consumption of
bandwidth. Adding the code to be more effective is apparently not worth it,
sad to say.
-Bill Kearney
----- Original Message -----
> I posted this idea on my blog [1], and Antone Roundy had a better idea
> than ttl -- putting the date and time the feed details were last updated
> in the element, like this:
>
> <rssboard:feedDetails lastUpdated="Tue, 13 Oct 2009
> 09:01:25 -0400">http://ekzemplo.com/feedDetails.rss</rssboard:feedDetails>
>
> That way, the client knows when the detail feed needs to be checked for an
> update, and never checks it otherwise.
>
> 1: http://workbench.cadenhead.org/news/3562
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
Rogers wrote:
> A publisher who wished to make use of this would be advised to
> move all channel elements except for title, link, description
> and atom:link to the detail URL.
I would think you'd still need to send the full feed by default for
backwards compatibility with clients that don't understand your new minimal
format. And then those clients that were willing to except the minimal feed
would include some kind of HTTP header to identify that capability to the
server.
At that stage though, you have no need for a link to an external source. If
a client decides that it wants the full feed details, it just doesn't
include the magic HTTP header. And if the server wants to force the full
details down to client in the event of an update, it can just ignore the
header (possibly based on etags or If-Modified-Since for clients that have
already been updated).
However, your problem now is how this will all be handled by proxy servers.
You're going to need to include a Vary header of some sort. How well that
works may depend on the kind of header you use to signal support for this
capability.
And at the end of the day, I'm not sure it's really worth all the effort.
You're proposing keeping a bunch of elements that I'd be happy to see
dropped, but not keeping ones that I'd consider essential. I imagine
everyone's opinion on this would differ though, so the end result may never
satisfy anyone.
With compression enabled, is it really going to save you that much
bandwidth?
Regards
James
* Rogers <cadenhead@...> [2009-10-13 16:40]:
> <rssboard:feedDetails lastUpdated="Tue, 13 Oct 2009 09:01:25
-0400">http://ekzemplo.com/feedDetails.rss</rssboard:feedDetails>
Since this is in a new namespace, is there a reason to prefer
RFCÂ 3339 over RFCÂ 822 format here?
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
--- In rss-public@yahoogroups.com, Aristotle Pagaltzis <pagaltzis@...> wrote:
> Since this is in a new namespace, is there a reason to prefer
> RFC 3339 over RFC 822 format here?
My thinking was that because the namespace was centered on RSS, it would be
better to use its date-time format. If it was expanded to support Atom, I would
have used RFC 3339 since that format is easier to parse.
--- In rss-public@yahoogroups.com, "Bill Kearney" <wkearney99@...> wrote:
> In theory this info is already coming with the feed as part of the > HTTP
headers. Use the data that's already present.
By "this info" you mean the date-time of last update, correct? I can see why it
would be better to make a HEAD request to the feed details feed to determine
whether it was updated, but it would mean an extra request most of the time to
be told there was nothing new.
> What evidence exists to prove there would be any uptake of it?
That's a good question. There's a chicken-egg problem here. If I adopted the
namespace today, it would make my feed less capable to every RSS client that
doesn't support the namespace.
Perhaps the namespace could be used only for requests from clients that support
RFC3229+feed, since they're already trying to optimize bandwidth and would be
more receptive to the proposal. Anyone know some of the bigger clients that
support this?
Randy Charles Morin made this comment on my blog: "A similar solution to
feedDetails is X-Include. It's already well documented and understood. A
downfall of these approaches is that they actually increases connections, which
is often more important than bandwidth when you are scaling RSS."
What do people think about putting these optional elements in a separate file
and using X-Include [1] to incorporate them? Would clients make HEAD requests to
determine whether they needed an updated copy, or just request the included file
every time they requested the feed?
1: http://www.w3.org/TR/xinclude/
* Rogers <cadenhead@...> [2009-10-15 14:20]:
> My thinking was that because the namespace was centered on RSS,
> it would be better to use its date-time format. If it was
> expanded to support Atom, I would have used RFC 3339 since that
> format is easier to parse.
It’s not just ease of parsing, it’s also 2- vs 4-digit years
(are you using RFCÂ 822 or RFCÂ 2822 format?), and the presence of
redundant information (the day name) that allows for properly
formatted but invalid dates (Fri, 15 Oct 2009 15:57:08 +0200).
I see no upside to this attempt at consistency. RFCÂ 3339
datetimes are nearly trivial to parse (which of course was the
whole point of that RFC), and in any case are already supported
by anyone who parses either Atom or the Dublin Core RSS extension
elements.
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
--- In rss-public@yahoogroups.com, Aristotle Pagaltzis <pagaltzis@...> wrote:
> I see no upside to this attempt at consistency. RFCÂ 3339
> datetimes are nearly trivial to parse (which of course was the
> whole point of that RFC), and in any case are already supported
> by anyone who parses either Atom or the Dublin Core RSS extension
> elements.
You're right. If this proposal gets any further, I will switch the date-time
format to RFC 3339.
The RSS Advisory Board is now running a local copy of the Feed Validator:
http://rssboard.org/rss-validator
I'm still making some adjustments to the presentation, but it looks like it
works properly. If you could test it with your own RSS feeds and let me know if
you encounter problems, that would be helpful.
The validator didn't have a "valid RSS" badge that includes the Feed Icon, so I
created one:
http://rssboard.org/rss-validator/images/valid-rss.png
I will try to keep the code up to date with the Feed Validator and contribute
any changes I make back to the project. So far it's running the exact same code.
The valid RSS badge is available for reuse under the Creative Commons
Attribution/Share Alike license [1]
1: http://creativecommons.org/licenses/by-sa/2.0/
Rogers wrote:
>
> The RSS Advisory Board is now running a local copy of the Feed Validator:
>
> http://rssboard.org/rss-validator <http://rssboard.org/rss-validator>
>
> I'm still making some adjustments to the presentation, but it looks like
> it works properly. If you could test it with your own RSS feeds and let
> me know if you encounter problems, that would be helpful.
>
> The validator didn't have a "valid RSS" badge that includes the Feed
> Icon, so I created one:
>
> http://rssboard.org/rss-validator/images/valid-rss.png
> <http://rssboard.org/rss-validator/images/valid-rss.png>
Deployed on feedvalidator.org. :-)
> I will try to keep the code up to date with the Feed Validator and
> contribute any changes I make back to the project. So far it's running
> the exact same code.
You already have commit access. Let me know if I can help in any way.
> The valid RSS badge is available for reuse under the Creative Commons
> Attribution/Share Alike license [1]
>
> 1: http://creativecommons.org/licenses/by-sa/2.0/
> <http://creativecommons.org/licenses/by-sa/2.0/>
- Sam Ruby
Rogers wrote:
> The RSS Advisory Board is now running a local copy of the Feed Validator:
>
> http://rssboard.org/rss-validator
Cool. Tried a few tests and it's working nicely for me.
Regards
James
Thanks Rogers!
--- In rss-public@yahoogroups.com, "Rogers" <cadenhead@...> wrote:
>
> The RSS Advisory Board is now running a local copy of the Feed Validator:
>
> http://rssboard.org/rss-validator
>
> I'm still making some adjustments to the presentation, but it looks like it
works properly. If you could test it with your own RSS feeds and let me know if
you encounter problems, that would be helpful.
>
> The validator didn't have a "valid RSS" badge that includes the Feed Icon, so
I created one:
>
> http://rssboard.org/rss-validator/images/valid-rss.png
>
> I will try to keep the code up to date with the Feed Validator and contribute
any changes I make back to the project. So far it's running the exact same code.
>
> The valid RSS badge is available for reuse under the Creative Commons
Attribution/Share Alike license [1]
>
> 1: http://creativecommons.org/licenses/by-sa/2.0/
>
A proposal has been made for the RSS Advisory Board to take over publication of
the Media-RSS specification and maintenance of the RSS-Media mailing list.
Details here:
http://tech.groups.yahoo.com/group/rss-board/message/295
We welcome comments from the public on the proposal.
I support the proposal.
Joly MacFie
On Tue, Nov 24, 2009 at 2:29 PM, Rogers <cadenhead@...> wrote:
> A proposal has been made for the RSS Advisory Board to take over
> publication of the Media-RSS specification and maintenance of the RSS-Media
> mailing list. Details here:
>
> http://tech.groups.yahoo.com/group/rss-board/message/295
>
> We welcome comments from the public on the proposal.
>
>
> --
---------------------------------------------------------------
Joly MacFie 917 442 8665 Skype:punkcast
WWWhatsup NYC - http://wwwhatsup.comhttp://pinstand.com - http://punkcast.com
---------------------------------------------------------------
[Non-text portions of this message have been removed]
The proposal to take over mRSS has passed unanimously.
http://tech.groups.yahoo.com/group/rss-board/message/316
Thanks,
Randy
--- In rss-public@yahoogroups.com, "Rogers" <cadenhead@...> wrote:
>
> A proposal has been made for the RSS Advisory Board to take over publication
of the Media-RSS specification and maintenance of the RSS-Media mailing list.
Details here:
>
> http://tech.groups.yahoo.com/group/rss-board/message/295
>
> We welcome comments from the public on the proposal.
>
As part of the RSS Advisory Board becoming custodian of the Media RSS
specification, I've prepared a copy of the spec here:
http://www.rssboard.org/media-rss
This is a draft copy of the current version of the spec that still requires some
proofreading. Your help would be appreciated.
The namespace declaration will remain http://search.yahoo.com/mrss/ even though
the board is now publishing the spec.
While I was preparing the document, I fixed some typos, HTML markup errors and
two examples that did not follow the spec. I also added the geoRSS namespace
declaration to the last example.
The specification now has a Table of Contents and internal links to each
element, making it easier to refer to them here on RSS-Media and elsewhere:
http://www.rssboard.org/media-rss#table-of-contents
One thing I could not fix involves this line in the Change Notes:
"Modified ????? to have a URL attribute for better module consistency."
I can't find an older version of the spec that indicates which element was
modified to add a URL attribute.
On behalf of the board, I'd like to thank Sapna Chandiramani and the other
members of Yahoo who have worked on the spec for the past five years.
The board is also taking over management of RSS-Media, the mailing list for the
public to ask questions, offer feedback and discuss implementations of the
namespace.
Rogers wrote:
> One thing I could not fix involves this line in the Change Notes:
>
> "Modified ????? to have a URL attribute for better module consistency."
media:thumbnail - the attribute used to be "href". You can still find
examples of the old usage out there.
And it was changed to a "url" attribute not a "URL" attribute.
Kind of tragic when you realise that version 1.5.0 just threw all that
consistency out the window.
Regards
James
0329200717250000
-----Original Message-----
From: James Holderness <j4_james@...>
Sent: Saturday, September 19, 2009 5:13 PM
To: rss-public@yahoogroups.com
Subject: Re: [rss-public] Use case for RSS XML Namespace: RssCloud Atom
Extension
masonglee wrote:
> I think I have another good use case for there being a "recognized"
> namespace to use when reusing the RSS schema elements out of RSS context:
>
> http://masonlee.org/2009/09/11/rsscloud-atom-extension/
From the rsscloud.org website:
"Just define a namespace to have a single element in it, the <cloud> element
from RSS 2.0.
If you need a URL for the namespace, please consider using the URL for this
site. "
That implies a one-off namespace for just the cloud element, which I'm not
sure is a great idea, but it appears to be Dave's current recommendation. We
shall see whether that gains traction or not. AFAICT Wordpress doesn't yet
support RSS cloud in their Atom feeds.
Regards
James
[The entire original message is not included]
[Non-text portions of this message have been removed]
-----Original Message-----
From: Rogers <cadenhead@...>
Sent: Saturday, September 19, 2009 10:26 PM
To: rss-public@yahoogroups.com
Subject: [rss-public] Re: Use case for RSS XML Namespace: RssCloud Atom
Extension
--- In rss-public@yahoogroups.com, "James Holderness" <j4_james@...> wrote:
> That implies a one-off namespace for just the cloud element, which I'm not
> sure is a great idea, but it appears to be Dave's current recommendation We
> shall see whether that gains traction or not. AFAICT Wordpress doesn't yet
> support RSS cloud in their Atom feeds.
A better way to handle the use of RSS elements in other XML dialects would be
the proposal we've been batting around. Revise the RSS spec to declare that when
RSS elements are used in other formats, the namespace URI should be
"http://www.rssboard.org/rss-namespace", but that RSS itself does not have a
namespace.
Dave's RSSCloud proposal is another use case for the need to have a namespace
for RSS used elsewhere.
[The entire original message is not included]
[Non-text portions of this message have been removed]
deeparaokv wrote:
>I was surprised to see that the Google News RSS feed fails to get
> validated on the http://feedvalidator.org/ This is the RSS URI I
> provided from the http://news.google.com/ -
> http://news.google.com/news?pz=1&cf=all&ned=us&hl=en&output=rss Have
> anyone tried this before ? Or am I providing a wrong Google news RSS URI
> for validation? Pls help. Thanks!
That's the current URL for their feed - it's just not valid.
It looks to me like it's just a case of an invalid timezone in the various
date elements - should be "GMT" not "GMT+00:00".
The rest of the problems reported are just warnings. Nothing too serious,
although the "Misplaced Item" warnings are interesting. That's the result of
the channel description element being included at the end of the feed, after
all the items. I'm curious what effect that'll have on feed readers.
Regards
James
I have been fighting with Feedburner for the past 4 hours and I cannot clear
their data from my blog. I keep getting a error 404 relating to URI being
striped from my template. I have viewed several help groups and even when onto
the oracle site for help with java as it relates to this whole problem. Bottom
line, Feedburner needs to release old data from URL's and it's not. I cannot
get beyond this issue
Pat
Send Email
