The goal is to develop a new specification from scratch, code-named "Site Syndication Format," that clarifies or corrects these issues -- which can then be submitted to UserLand Software, a standards body, or published as a profile describing RSS 2.0 best practices. The list's members will vote on the final disposition of the new specification.
The members of the list should be developers who have written software that produces or consumes RSS 2.0.
I'm moderating the list so that it remains focused on answering a simple question: What parts of the format as presently specified are genuinely broken for implementors and what can be done to most easily fix them?
One of the questions I expect people to ask about this list is why I'm on it, since I'm not an RSS developer aside from a few trivial Java applications that scrape Web pages.
I'll gladly relinquish the moderator position if another developer wants to take it on. Until then, though, I think it's valuable to follow the RSS 2.0 roadmap and draft a new specification of the format under a distinct name.
Whether this effort results in a better RSS 2.0 specification, a specification that can be submitted to a standards body, or simply a "best practices" recommendation depends on the final vote of the members.
I was trying to respect the roadmap for RSS 2.0 and minimize confusion. Site Syndication Format is merely a name for the draft document as it is being composed. If it ended up becioming the RSS 2.0 specification, that would be great. If not, I'd like to avoid creating more confusion about RSS. No one appears to be calling anything Site Syndication Format or SSF, so it seemed like a safe place for a working group to camp out for a while.
Namespace please. If it makes people who aren't using XML libraries unhappy, screw 'em. They should be dealing in XML, not regex. I just tried to write a parser for RSS in XSLT, which would normally be trivial to separate out different dialects based on namespace, but no, you don't use one for RSS 2.0 ......
The RSS 2.0 spec is clear on the issue of namespaces: "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."
It's beyond the scope of this effort to discuss improvements to RSS 2.0. We're just looking for and resolving ambiguities that prevent an implementor from knowing what to expect or what to create in the format as it presently exists.
I'm still a little confused - if the idea is to "develop a new specification from scratch" then why not join the Echo project. If the idea is to write a proper specification for RSS 2.0 (with a DTD perhaps? ;-), then what needs doing from scratch?
Since UserLand owns the copyright to the existing RSS 2.0 specification but disclaims any copyright to the format itself, there's a good opportunity to write a new specification from scratch that clarifies any existing problems and clearly documents everything else.
There are three possible outcomes that are positive:
1) UserLand adopts the finished product as the RSS 2.0 spec, or
2) The new spec, by codifying RSS 2.0 in a clear manner through a collaborative effort, is suitable for a standards body to consider, or
3) The finished product becomes an RSS 2.0 "best practices" guide for people who need more help interpreting the existing spec.
Now there's a positive approach. It seems if a focused body can resolve ambiguities in RSS 2.0, this could only be a Good Thing. Perhaps convergence is still possible.
But, Rogers, don't you think a few more technical writers should be on the list?
The more the merrier -- especially if they have experience writing a spec.
Any chance of a DTD and XML Schema?