RSS namespace proposal
Here's the set of changes I would propose to RSS 2.0:
- Items in a RSS 2.0 feed today are unqualified by a namespace. The proposal is that namespace qualified items to also be supported. If aggregators are coded correctly, this shouldn't cause any breakage. True, some may not "see" the new items, just like the way that some don't "see" the relatively new guids. However, some will work without change, just as many did when scripting.com's 2.0 feed had a namespace. And the change required to fully support this namespace should be small for those aggregators that require a change at all.
- It would be nice if channels could also be in a namespace. This could be achieved in the same way.
- Today, the outermost rss element is unqualified by a namespace. I am explicitly not proposing that this be changed in any way. In fact, there is no need for the version number inside that element to change. But if people felt that it was more appropriate to mark such feeds up front as, say, 2.1, then I'm OK with that too.
- What should the namespace be? I could propose one of my own, and while that would be technically legal, morally it would feel like stealing to me. I would prefer that either Dave Winer proposed one, or that one be established as a part of the IETF standardization process.
- Should there be one namespace or multiple? Nothing above indicated that the same namespace need be used throughout, just that unqualified elements still need to be accepted. Perhaps it might make sense to identify a core and to group related elements? Perhaps not. I don't feel strongly about this one.
- Should the existing specification be tightened up in terms of what is allowable? IMHO, no. Not if it is done in a way that makes existing feeds invalid.
= = =
Summary: At a minimum, I'd like to see an optional namespace be identified for items. Ideally, this would work for channels too. Nothing more need be done.
I don't see why you need anyone's approval. AFAIK, Dave doesn't care about namespaces in RSS, except the few he's created. mnot's Internet Draft of RSS 2.0 has already been published, and it doesn't mention anything more about namespaces than Dave's original RSS 2.0 spec, so it doesn't seem appropriate to stuff it in there. (It may be appropriate in the future to write a followup draft to formalize common namespaces.)
So what are you waiting for? Propose something concrete and let's get major aggregator vendors to support it (or at least not choke on it).
Posted by Mark atSam, I suggest you post a request for comments on the RSS2-Support mail list. I will follow that with a question about breakage. That's my major concern.
There was a promise made in RSS 2.0, and I don't doubt that many people take it seriously. I do. The promise was that the boat-rocking would end now, and it would be safe to deploy. That's what the roadmap means. If we can have flexibility without breakage, great. If not, then it's time for a fresh beginning, which wouldn't be a bad idea anyway, imho.
BTW, I agree with you about new innovative uses for RSS. I can't wait to tell you about the one Jeremy Allaire had in mind. It's a hum-dinger!
Posted by Dave Winer atI tend to agree with Mark; I wouldn't think people would argue too much about just a namespace (although I'm sure folks will come out of the woodwork!).
If you do porpose something quickly, and there isn't too much argument about it, I can get it into NewsGator 1.2 which should be released in a week or two.
Posted by Greg Reinacker atDave, I did speak for myself; AFAIK means "as far as I know". Look it up.
http://dictionary.reference.com/search?q=afaik
I will, however, rephrase: "I have never seen Dave express an opinion, positive or negative, about any RSS namespace that anyone else has ever proposed for any purpose." However, since I stopped reading Scripting News several months ago, it's quite possible that you expressed such an opinion and I missed it.
The original point stands; you specifically engineered RSS 2.0 so that nobody needed your approval to create new namespaces. Which is great. Sam is now proposing to create a new namespace, and it seems odd to me that he says he would feel better if you named it. Wasn't one of the primary reasons for allowing namespaces in RSS 2.0 was so you could get out of the business of extending RSS? (cf. fullitem, pubDate, Jon Udell's extensions to 0.92)
Also, AFAIK, your existing RSS consuming products wouldn't be affected in any way. I base that statement on the fact that they were unaffected during the brief trial period when scripting.com/rss.xml had a namespace. Sam's concerns about backward compatibility only concern namespace-aware XML parsers that treat lack-of-namespace differently from explicit-namespace. Simon Fell's RSS test suite shows that your products do not behave this way, hence, this proposed change would not affect your products. Hooray for forward-compatible parsing.
Posted by Mark atMy preference would be for the way a namespace was done for the brief period when Dave's RSS feed had a namespace, that is, a default namespace of "http://backend.userland.com/rss2", if I recall correctly. Which means the 'rss', 'channel' and 'item' elements were all in that namespace. I have several reasons for preferring it that way:
Breakage: The last time it was tried only a couple home brewed aggregators broke, and they were fixed shortly.
Laziness: At least laziness on my part, as Aggie is already setup to process feeds that work this way. It will actually use whatever namespace the 'rss' element is in.
Posted by joe atOh I see. And I assume the crap on your site today is all under a big AFAIK.
Let me add this. AFAIK, Mark Pilgrim's credibility on all things I do is nil.
Posted by Dave Winer atRSS fixins'
Tim Bray, RSS Needs Fixing: Because, boys and girls, RSS is no longer a science experiment, it's becoming an important part of the infrastructure, which means that a lot of programmmers are going to get the assignment of generating and parsing it,...Excerpt from Blogging Roller at
The past, present, and future of RSS
Sam writes some article/blog entries on RSS: The Future of RSS, Ghosts of RSS Past, RSS: it's not just for... [more]Trackback from techno weenie at
RSS 2.0
Sam has a whole pile of entries on RSS 2.0, which I fully support. Dave Winer is worried about breaking existing clients, but I think that we still have only seen a fraction of the RSS use that we are going to see. Breaking RSS on last... [more]Trackback from Ted Leung on the air at
Mark, obviously there's nothing I can say that you can't complain about. Whatever. Have fun.
Posted by Dave Winer at
Distributed RSS Discussion
There’s an interesting distributed discusson on RSS’s past, problems, and possible future going on, includng a concrete proposal for how to move RSS 2.0 to a fully-embeddable namespace-protected format.... [more]Trackback from Mt. Molelog at
Hi Sam,
A point of clarification:
Are you proposing only the item element be in a namespace, or that all the core RSS 2.0 sub elements under item too?
Using two example for clarification, are you talking about:
#1
<pre>
<ns:item xmlns:ns="urn:rss2something">
<title>The Example Item</title>
<link>
http://example.org/item/
</link>
</ns:item>
</pre>
or
#2
<pre>
<ns:item xmlns:ns="urn:rss2something">
<ns:title>The Example Item</ns:title>
<ns:link>
http://example.org/item/
</ns:link>
</ns:item>
</pre>
?
Interestingly, the latter bears some striking similarities with the concept of extension modules in RSS 1.0
- see mod_event for example.
http://dmoz.org/Reference/Libraries/Library_and_Information_Science/Technical_Services/Cataloguing/Metadata/RDF/Applications/RSS/Specifications/RSS1.0_Modules/
So RSS becomes a feed of encapsulated payload entries (items), each of which would/should have an agreed definition (Schema) in its own namespace.
A follow on question then is whether there are any "core" elements which would be present in all item types (like title, description and link etc in RSS 1.0)
Maybe that's where Dublin Core steps up to the plate - dc:title dc:description would seem to fit the bill. Not sure what link translates to though - a rdf:about attribute (a'la RSS 1.0) does not seem to fit the pattern.
- Jorgen
Posted by Jorgen Thelin atRSS 2.0
Sam has a whole pile of entries on RSS 2.0, which I fully support. Dave Winer is worried about breaking existing clients, but I think that we still have only seen a fraction of the RSS use that we are going to see. Breaking RSS on last time now is...Excerpt from Ted Leung on the air at
The Future of RSS
Sam Ruby has been pouring out thoughts on RSS today: RSS Namespace Proposal RSS: It's Not Just for Syndication Anymore Ghosts of RSS Past These entries read either as an essay that looks like a series of posts or a series of posts that look like an...Excerpt from Matt Croydon::postneo at
Evolution of RSS
Sam is thinking good thoughts about the future of RSS. Others are agreeing with him. Dave continues to fight the future present. Mark continues to have fun. Life is good... [more]Trackback from snellspace at
Getting the RSS 2.0 namespace right
Last time we discussed a namespace for RSS 2.0, I got it wrong, proposing the right thing to do as my third proposal and bad-mouthing it. This time, I'd like to see it done right.... [more]Trackback from phil ringnalda dot com at
In brief: insomniac edition
A little of everything. I mean, why not? I'm up anyway.... [more]Trackback from dive into mark at
Why all this discussion on RSS 2.0 namespace? Why not just concetrate on RSS 1.0 which already has a namespace. Personally, I feel it's added complexity is minor, its spec is better written and concise, and it easily allows for extensions (xhtml:body) and embbeding within other xml (well anything within the http://purl.org/rss/1.0/ namespace and modules).
Posted by Jonathan Porter at
If RSS 2.0 items were more embeddable
Sam Ruby: Ghosts of RSS past... Why embed XHTML into RSS when we can embed RSS into XHTML?...Excerpt from snellspace at
Sam Ruby -Why we should iterate the RSS format to use optional namespaces
Sam kicks butt in these posts (we're lucky to have his analytical clarity in the blogging community): Ghosts of RSS past RSS: it's not just for syndication anymore RSS namespace proposal <quote> Summary: At a minimum, I'd like to see an...Excerpt from Roland Tanglao's Weblog at
Sam Ruby’s last few posts about RSS past and ...
Sam Ruby’s last few posts about RSS past and future help to explain why it needs namespaces (or some other change), which helped clear my previous confusion. Future apps. That makes sense (but for weblog aggregation? I'd still argue against a...Excerpt from phil.wilson - a geek commodity at
If you're going to have optional namespaces, might as well have it for the<rss> element too; I would want to embed a whole RSS feed as often as I would a channel or item.
As regards relative URIs, my ongoing post oversimplified, but the answer is even simpler. All we need to do is establish a convention that RSS readers obey the xml:base= attribute, which is not ruled out by anything in the current RSS2 spec.
Posted by Tim Bray atAnd, my hamsterness aside, if you embed an RSS 1.0 item by itself using the RSS 1.0 namespace you will:
1. Probably lose the RDF-ness of it.
2. Have to add not only the RSS 1.0 namespace but the RDF namespace as well, since your item will have an rdf:about attribute.
Hi Sam!
Speaking of which, did you ever figure out how to embed RDF into a SOAP wrapped RSS item? http://www.intertwingly.net/blog/1290.html#c1048265196
Posted by joe atJoe,
It is quite simple. In rdf, one may put a marker element <rdf:RDF> immediately around the rdf specific content.
So, my implementation of the commentAPI will optionally accept either of the above and respond in kind.
Posted by Sam Ruby atSam writes, "It is quite simple. In rdf, one may put a marker element <rdf:RDF> immediately around the rdf specific content."
That's misleading. The RDF spec says (sec. 2.2.1), "The RDF element is a simple wrapper that marks the boundaries in an XML document between which the content is explicitly intended to be mappable into an RDF data model instance. The RDF element is optional if the content can be known to be RDF from the application context."
The most obvious place where the content would be known is if the entire document instance is RDF. In theory, another context could be to look for elements with an rdf:about.
I'm not aware of any RDF tools that support the latter, and very few the former -- so the use of "may" in your comment is not supported by any interoperable means.
How can we get past this vagueness?
Posted by Ken MacLeod atKen - we can get past this vagueness if the spec were to change. As long as the spec says "optional", I believe it it reasonable for me to say "may". If the spec were to change, then I would do likewise.
Meanwhile, the way I have implemented the commentAPI is as follows: if the request has an RDF marker, then the response WILL too. If such a marker is not present in the request, then it won't be present in the response.
This lets me interoperate with both the hamsters and those who know better. I know of people who implemented clients that do not send such marker elements. Do you know of people who have implemented clients that do?
Posted by Sam Ruby atSo it's just like the SOAP spec, which says the item in the SOAP:Body may be in a namespace.
Posted by joe at
joe, is there still a question about how to include the RDF? I'd recommend using the <rdf:RDF> element.
Posted by Ken MacLeod at
Joe: I have no problem with may. What I have a problem with is may not. If adding a <rdf:RDF> element enables more tools to consume this information, then what's the harm?
My preference is to treat such mays as shoulds, thereby being liberal in what I accept but conservative in what I produce.
Posted by Sam Ruby atYour link to validator.w3.org
I saw your link to validator.w3.org on your webpage
http://www.intertwingly.net/blog/ and thought that our site
www.HTMLCodeTutorial.com may be of help to your visitors. Our users
commonly comment that HTML Code Tutorial is one of the best on the web;
and we recently added a Help Forum, which you can click on from the home
page and get personalized help. We would be grateful for a link to our
site from your site.
Email me if you have any questions.
Thanks,
Dan
Emailed by Dan at
In brief: 26th April 2003
RSS galore: what's in the future of RSS? Mark Nottingham is trying this: an Internet Draft of RSS 2.0. In the meantime, Sam Ruby elaborates: RSS Namespace Proposal, RSS: It's just not for syndication anymore, Ghosts of RSS past, Future of RSS. Then,...Excerpt from Through the Blogging-glass at
RSS - The Sledge-o-Matic of Markup
Long time no talk about RSS, but I'm overdue. Thanks to a pointer from Sam, I read The article Why Blogs haven't stormed the business world. According to it, the reason why more weblogs aren't in use today is because it's too difficult to move... [more]Trackback from Burningbird at
Sam Ruby -Why we should iterate the RSS format to use optional namespaces
Sam kicks butt in these posts (we're lucky to have his analytical clarity in the blogging community): Ghosts of RSS past RSS: it's not just for syndication anymore RSS namespace proposal <quote> Summary: At a minimum, I'd like to see an...Excerpt from Roland Tanglao: XML at
Sam Ruby -Why we should iterate the RSS format to use optional namespaces
Sam kicks butt in these posts (we're lucky to have his analytical clarity in the blogging community): Ghosts of RSS past RSS: it's not just for syndication anymore RSS namespace proposal... [more]Trackback from Roland Tanglao's Weblog at
RSS - The Sledge-o-Matic of Markup
Long time no talk about RSS. I'm overdue. Thanks to a pointer from Sam, I read The article Why Blogs haven't stormed the business world. According to it, the reason why more weblogs aren't in use today is because it's too difficult to move content from one tool to another: The greatest problem, however, is not the limitations of the front end of this software, but rather what goes on behind the curtain, so to speak. As bloggers add content to their sites, the programs...... [more]Trackback from Burningbird at
Sam wants namespaces
Sam proposes some changes to RSS 2.0 regarding namespaces. My first question was, "why?" but upon reading his next post,... [more]Trackback from mnot's weblog at