Shall we run an experiment is to see if aggregators can work with RSS feeds that have a xmlns attribute at the top level, on the <rss> element?
Consider this feed and its top level <rss> element. <rss version="2.0" xmlns="http://www.rssboard.org/rss-specification">.
Now, the RSS spec doesn't say that this is okay, but neither does it say it's not okay. You might want to include bits of RSS in other formats, say SOAP or SVG, in which case we'd need a namespace identifier for the vocabulary defined by RSS 2.0. If we manage to jump over this hurdle, let's say that the namespace is identified by the address above. It seems as good as any other.
Let's find out how various aggregators, in Summer 2003, work with the test feed.
To see if they work:
- Subscribe to the feed.
- If a new item appears, it worked; if not it didn't.
Strictly speaking, it's not a bug if it doesn't work; in fact it won't work in rigorous RSS parsers.
The question is -- should it? That's open for discussion.If it doesn't work and you want it to work, make it so that your parser looks for item, title, link, description -- the core RSS 2.0 elements -- first in the nil namespace (that's how it works now) and if it doesn't find it, look in the namespace identified by this address: http://www.rssboard.org/rss-specification.
If your aggregator can make sense out of the sample feed, without any knowledge of the address for the RSS 2.0 namespace, you might consider that a bug. Would your aggregator also understand items in a different namespace? Please comment here.
Those are old results. The aggs have changed.
www.mnot.net
Looks like pretty up-to-date results to me.
RFC (following example of <rss/> element in a namespace other than the default): "Now, the RSS spec doesn't say that this is okay, but neither does it say it's not okay."
Spec: "The elements defined in this document are not themselves members of a namespace..."
Therefore it's not okay!
Graeme: Thanks for checking.
To Aaron, sorry for the confusion. I saw an old version of something that looked like that, jumped to a quick conclusion.
I learned something today, and that's cool.
Now Bill Kearney will say I should use RDF.
Have a great day.
Some XML clarification :)
The null namespace is just that - a namespace like any other, it just happens to have a "null" identifier. An element in that namespace does not match any element in any other namespace.
So <rss/> does not have any relationship to <rss xmlns="..."/>. The fact that their local names ("rss") happen to be the same doesn't matter.
Because the spec says the RSS elements have "no namespace", any aggregator which interprets an RSS element which is in a different namespace is wrong to do so.
So to answer your question :), today's aggregators are being extremely loose in an XML sense. They're comparing XML apples to XML pears and deciding they're the same.
>Graeme: "They're comparing XML apples to XML >pears and deciding they're the same."
So, in essence, aggregators are just like HTML browsers wildly interpreting broken HTML as best they can. Sounds like normalcy to me!
Sad, but true :(
HTML went through the same problems and we've ended up with XHTML. Unfortunately todays browsers still have to parse and handle badly formed HTML as well as XHTML.
RSS needs to change quickly to stand any chance of avoiding the same fate. If only RSS had an XML Schema to start with...
...That's assuming it didn't! ;)
Should use RDF? No, I've completely given up on thinking you'll ever be capable of grasping the value of RDF. I'd be content just to have you shut up about it. That's also a hope I'm sure is unlikely to be fulfilled.
It takes a bigger man to stop addressing such blatantly obvious trolls.
Hey Bill, my Kearney Number just went up!
"cheesecake"
BTW, I did use RDF in the Trackback implementation in Manila and Radio. So there! ";->"
And obviously neither of you are it ;)
SharpReader v0.9.2.0 doesn't consider this feed to have any items and while you can subscribe to it, it does not consider the title of the feed to be the rss title so it is blank in the GUI.
Using James Clark's XML Namespaces shorthand notation I also linked from that comment, you are asking, can a reader first check for an element name '{}rss' and then check for an element name '{http://blogs.law.harvard.edu/tech/rss}rss', the answer is: yes. Logically, that's the difference between them. Different toolkits will represent those differently (such as a tuple, seperate arguments, or structure fields) but, logically, when using XML Namespaces, the name of an element or attribute is always the pair of Namespace URI and local name.
(Note, I'm using braces above, as Clark's notation uses, but the blog is converting them to character entities and some code in the pipeline is not processing the ';' after the character entity properly.)
SharpReader is namespace-aware and therefore will not read a feed with an unknown namespace. At one point or another there was talk of using purl.org or backend.userland.com as a namespace for RSS 2.0, and SharpReader accepts both of these. I can easily add another one if everyone can agree on the URL to use...
Please note that assigning a URI to the default namespace only affects elements, not attributes (by default, these are in the null namespace).
It's a really, really good idea to put a namespace on the RSS element, and it's a really, really, good idea to make sure that it works with legacy software that can't be upgraded. XHTML did this, and it works.
But it's not a good idea to give up because of Perl modules that have to be updated to know about a new namespace; just fix them. That's what CPAN is for. It's not a good idea to give up because the Harvard-hosted description of RSS 2.0 doesn't mention a namespace. It's not a standard, it's not a recommendation, and it's not an IETF RFC. It's a work in progress. So, decouple the issues by putting in a namespace, and proceed! Pick a URI for the namespace, and plan to change it as the definition converges.
This work really should be brought to IETF, and follow RFC 3470 best practices for XML within IETF protocols. I believe a rough consensus can be arranged, and I believe it can and must include namespaces.
Leigh: actually, the RSS spec is not a work in progress. It's a frozen spec. It says so itself, and the spec author (Dave) has been consistent and clear on this point. Furthermore,
"""The elements defined in this document are not themselves members of a namespace, so that RSS 2.0 can remain compatible with previous versions in the following sense -- a version 0.91 or 0.92 file is also a valid 2.0 file. If the elements of RSS 2.0 were in a namespace, this constraint would break, a version 0.9x file would not be a valid 2.0 file. """
The spec author has always maintained that this sort of compatibility (RSS 0.91 is valid RSS 0.92 is valid RSS 2.0, just change the version attribute) is important, because to do otherwise would create a discontinuity.
scriptingnews.userland.com$1744#discontinuities
The same definition of compatibility has led to a somewhat absolutist stance on never obsoleting, replacing, or even deprecating existing elements. Thus the firm stance against "funky RSS", where the functionality of core elements was duplicated in namespaced elements.
backend.userland.com
And yet, in the past week alone, we've seen proposals for (1) moving all the core elements into a namespace (which would create a discontinuity), and (2) replacing webMaster, managingEditor, and author with namespaced equivalents (which would be funky by the above definition).
I'm puzzled.
Mark, your puzzlement is self-created. No one ever said that webMaster, managingEditor or author would be replaced. It was a feature request from a friend of yours, and we were trying to help. That's all. It would not be "funky" to use it, if you had a real need for it. Also, the word "moving" is probably inducing the confusion for you. Again, we were just investigating to see if a feature request could be accomodated. You know in the Mark Pilgrim Environment, just trying something out is something one has to defend against. Not much fun. May I suggest that you stick to your promise that you don't care about RSS, and get on with defining your own formats and protocols. Then you can learn the pleasures of having people take shots at you from the cheap seats.
Dave, flames like that will never get you anywhere. You really should learn how to do advocacy better. Here's a document that might help:
www.ibiblio.org
Meanwhile, my points stand. *If* you define a default namespace for RSS, (1) this *will* mean that valid RSS 0.9x feeds are no longer valid RSS 2.0 feeds, (2) this *will* break existing namespace-aware parsers, (3) this *will* create a "discontinuity", as you yourself have defined the term, and (4) this *will* directly contradict the roadmap that you yourself laid out in the RSS 2.0 specification. Whether you not you *actually* go through with it is irrelevant; given your previously unwavering positions on all of these issues, I am puzzled that you would even consider it.
That's one of the sore points in past debates regaring RSS, the whole notion of Winer's "unwavering postitions".
It been nigh-on-impossible to get things clarified by Dave because of his past track record of being unwilling to take one step backward in order to get three GIANT steps forward. There's a perception it's more about 'saving face' than it's ever about actual progress. Some of the issues, like namespaces, have been shrouded more in myth than facts. Combine that with the 'unwavering postition' aspect and the whole thing just falls apart.
The people that DO understand the complex issues (and how to truly make them really, really simple) find that unless Dave somehow magically grasps the idea, it's pointless to bother trying anymore.
It's a wiki and as such is completely open to having edits applied to it. Feel free, Dave, to help out the community by making contribtions to the wiki that clarify the results.
Prayer Mat Price in Pakistan - Discover competitive prayer mat prices in Pakistan at QudratUllah. We offer a range of options to suit every budget without compromising quality. Shop now and find the ideal prayer mat that fits your needs.
