The following RSS Advisory Board proposal has been made by Randy Charles Morin and seconded by Rogers Cadenhead.
Under the advisory board charter, the board has seven days to discuss the proposal followed by seven days to vote on it. Interested parties can comment on the proposal on the mailing list RSS-Public.
Proposal
We'd like to propose a small clarification to the RSS 2.0 specification to remove uncertainty in the community over whether extension attributes are allowed to core RSS elements.
In the section Extending RSS, we propose that the following sentence be changed:
A RSS feed may contain elements not described on this page, only if those elements are defined in a namespace.
It should be revised to read as follows:
A RSS feed may contain elements and attributes not described on this page, only if those elements and attributes are defined in a namespace.
Rationale
When namespaces were added to RSS 2.0 by Dave Winer in 2002, he wrote on his weblog that he was deferring the details of their implementation to the Namespaces in XML specification:
I've added the section explaining how to extend RSS through namespaces. I'm basically telling you to ask the W3C how namespaces work, and do it the way they tell you to do it. I don't want to assume the problem of documenting namespaces in the RSS spec.
When namespace support was added, that version of the specification linked to a new RSS 2.0 sample file that used them. This sample file was part of the specification for the next two years.
The first line in the sample file makes use of a namespace attribute:
<rss version="2.0"
xmlns:blogChannel="http://backend.userland.com/blogChannelModule">
In the above, xmlns:blogChannel is a namespace attribute contained by the rss element that declares the blogChannel namespace.
The proposed spec revision makes it clear that this is valid RSS. If namespace attributes aren't valid RSS, every RSS feed that declares a namespace in the rss element is invalid.
Some namespace developers, most notably Microsoft, have employed namespace attributes on core elements.
To clear up confusion, support implementers who've emulated the specification, and give more clear guidance to namespace creators, this is an important and necessary clarification.
Yes, i agree. It is much better now.
Regards/Filipe
One can make a reasonable case that since namespaced elements are explicitly allowed in RSS 2.0, and that the spec for the Namespaces in XML document is explicitly referenced, that xmlns attributes are allowed. I am not aware of anybody questioning that.
What I fail to see is the leap from that point to a statement that allows arbitrary attributes in arbitrary namespaces on every core element. Adding such a capability goes beyond mere clarification.
This is also not the way that W3C specified attributes typically work. For example, see the specs for xml:base and xlink.
I further expand on this comment here.
The xml:base limitation you mention comes from the spec that introduces XML Base. I don't see where that kind of self-imposed limitation has bearing on another spec.
If I were to create an RSS namespace with a global attribute "contentmodel:type", I could require that it not be used on core elements. Or require that it only be used on item-description. Neither rule has any effect on what other namespaces require.
You call it a "duh!" that xmlns: attributes be allowed in core RSS elements, but at the same time you find in the RSS 2.0 spec a hard restriction against other attributes. How is that not inconsistent?
Let's see. "A RSS feed may contain elements not described on this page, only if those elements are defined in a namespace.", points to a spec that tells you how to do it (that spec describes xmlns attributes), and points to an example (since removed) which shows xmlns attributes. That sounds pretty convincing.
But let's explore the alternative. One thing that the spec doesn't say is that an RSS feed may not contain attributes that are not described on this page (irrespective of namespace). So by this reasoning, the spec allows, say, "rel" attributes on link elements and "type" attributes on title elements.
If you take the position that "everything not expressly forbidden by this spec is allowed", this alleged "clarification" is now imposing a restriction that previously did not exist. This opens Pandora's box not only for rel and type attributes, but for everything from multiple enclosures per item to encoded HTML in titles. And where you end up is, for all intents and purposes, an entirely new syndication format no matter what you might want to to call it.
If, however, you take the position that "everything not expressly allowed by this spec is forbidden", you need to justify that xmlns attributes are allowed. But as I already said, I think there is a solid case to be made there. Perhaps not open and shut, but pretty solid.
A third option is to take the path that Don Park advocates, and you end up not with a "hard restriction", but a "warning". Which makes sense, as intelligent people have disagreed on this point. Like, for example, both you and Randy, last October.
Using a warning here would accomplish nothing but dodging the issue: "Don't extend RSS 2.0 with namespace attributes in your own namespace, because they might or might not be invalid, and if they aren't it would be bad."
Roger, think about the *purpose* behind validation. Validation for validation-sake serves no purpose.
Let me get this straight. Before we propose the change, RSS sucks because it's not clear. Now that we propose to clarify the spec, we shouldn't do it. Fetch me a rock!
RSS 2.0 is not clear on a number of areas. Produce a new spec, and you can achieve clarity, but the results will no longer be RSS 2.0.
P.S. clear specs simply have a different set of problems. For example, Atom clearly allows elements using namespace prefixes, but enough implementations for a long enough time have had issues in this area that it is clear that a warning is warranted here too.
Produce a new spec, and you can achieve clarity, but the results will no longer be RSS 2.0.
Your position is that RSS 2.0 must remain confusing or it's no longer RSS 2.0?
Sometimes a problem can't be solved but worked around. A teenager might be outraged by this but a wise man will nod and move on. No insults intended.
Confusing is a pejorative term. I'm sure that you can find someone who considers RFC 4287 confusing. But if enough people got together and decided they wanted to address deficiencies in RFC 4287, they could certainly do so, but they would not call their work RFC 4287.
Noorani Qaida Online - Learn the Noorani Qaida online with QudratUllah. Our accessible resources and materials make it convenient for you to practice and improve your Quranic reading skills from the comfort of your home. Start your journey today!
