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.
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]
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).
Sam, 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!
I 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.
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.
My 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.
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,...
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.
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:
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.
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...
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...
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).
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...
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...
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.
And, 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.
Sam 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.
Ken - 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?
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.
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.
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,...
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...
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]
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]