Meanwhile the RSS Advisory Board promotes an alternate URI, and are in the midst of a protracted effort which intends to replace the content of that specification with this one.
The new specification draft purges the roadmap, and makes a number of changes, such as allowing skipHours to be zero to 24 (a change with some basis), and permitting namespaced attributes to be added to existing RSS 2.0 elements (a change without basis).
I didn’t recall that your name was still in the draft of the RSS Profile, Sam. I posted a new update today to remove it, per your request. My apologies for overlooking it. You were removed from the draft spec last December.
In your summary of the present situation, you’re neglecting to mention some salient points.
The draft spec’s a proposal that hasn’t been voted on by the board yet.
The profile also is a proposal and it isn’t complete, as you can see from the To Do section.
Treating draft proposals as if they were official recommendations of the board is misleading. The board isn’t “selectively promot[ing] the use of Dublin Core,” or anything else in the profile, and it isn’t promoting the draft spec. The board’s promoting bupkiss until it votes on these proposals.
As for there being “two distinct RSS 2.0 specs,” you’re being overdramatic. There are no differences in RSS elements or attributes between the current RSS 2.0 specification published by the board or Winer’s archived spec. The only changes the board has made in the last year were administrative, such as updating the mailing list link from the defunct RSS2-Support to RSS-Public.
“The new specification draft purges the roadmap, and makes a number of changes, such as allowing skipHours to be zero to 24 (a change with some basis) ...”
... you should mention that you proposed that change.
“The new specification draft purges the roadmap, and makes a number of changes, such as allowing skipHours to be zero to 24 (a change with some basis) ...”
... you should mention that you’re the person who proposed that change, and your rationalization was that some versions of RSS have had a zero-based skipHours and others didn’t. Allowing both resolved the inconsistency while maximizing backwards compatibility.
I most emphatically did not suggest that the roadmap be purged.
I went back and added a link to my analysis/recommendation w.r.t. skipHours; and will further note that it was not only the case that different versions of RSS differed on this; it furthermore is the case that different “official” versions of RSS *2.0* differed on this subject.
“Namespaces served as the basis for Dave Winer’s original fork, the basis for a nasty smear campaign, and the basis for one of Dave’s fears.”
Sam, my old blog post you pointed to was not an attempt to smear against use of XML namespace to extend RSS. While I can see how readers could have misunderstood the post, my intention was to point out the ‘funkyness’ which was not about XML namespaces but about adding elements that replace existing RSS elements.
I have no problem with XML namespace-qualified elements and attributes being added to RSS as long as they augment instead of usurp.
You say that the new spec purges the roadmap. Then you use as an example changes in the draft spec. Changes happen all-the-time in drafts. Suggesting that implies something about the actually spec is quite devious on your part. I didn’t expect otherwise from you.
The way it played out was that dc:creator was specifically called out by you and others (I would have linked directly to your blog post, but the essential images links are broken) as “Destruction”, when in fact, dc:creator was in use in RSS feeds long before item author elements were created in an attempt to usurp this usage.
Where’s the outrage on that?
Meanwhile, an example of usage of dc:creator was publicly added to the RSS 2.0 specification (and then subsequently quietly removed).
And then the usual suspects used this as a rallying cry to thump competitors.
Is it this [link] , promoted by Dave Winer? This [link] , from the RSS advisory board? Or one of the other dozen or so incompatible formats . It doesn’t really matter. There’s...
I most emphatically did not suggest that the roadmap be purged.
True. But if you favor allowing 0 in skipHours, that’s going to be taken as a rejection of the roadmap by some people.
There’s a question I’d like to ask you, Sam, because I think it cuts to the real issue here: If the RSS 2.0 specification is not clear on an important subject — such as whether an item may contain more than one enclosure — how should this lack of clarity be addressed, and who should address it?
Sam, I was not aware of dc:creator being in the RSS 2.0 at some point. It was not there when I wrote the post. Was it in a draft version?
Even if dc:creator could be overlooked due to historic confusion, there was much more than dc:creator in the example I used. I wrote the post because a) ‘the usual suspects’ were waving the ‘funkiness’ flag without clearly explaining it, and b) I noticed proliferation of ‘replacement’ elements.
IMHO, RSS 2.0 full of replacement elements is just an apple inside an orange. This was why I suggested that folks who want to do that should start their own feed format. Well, now the world has Atom so let’s bury any past grudges if there are any.
Re RSS Board’s new RSS 2.0 spec, I’ll say this: I support Atom more than I support the new rewritten RSS 2.0 spec.
Roger, the board should have written a practitioner’s guidance to clarify and document industry practice, not rewrite an existing spec and release it under the same name and version. I don’t understand how so many smart people as a group can make such a major blunder?
The group hasn’t made that “blunder,” Don. The spec has yet to come up for a vote because it’s a work in progress.
As it states at the top of the draft spec, “Because this document has not been adopted by the board, current implementers should continue to rely on version 2.0.8.”
As for your suggestion, we’re creating a guide like that called the RSS best practices profile, which is also a work in progress.
There’s a question I’d like to ask you, Sam, because I think it cuts to the real issue here: If the RSS 2.0 specification is not clear on an important subject — such as whether an item may contain more than one enclosure — how should this lack of clarity be addressed, and who should address it?
Since you are asking my opinion, here it is: my issue with the board is narrow, but unfortunately longstanding.
Clarifying 0-24 and one enclosure and plain text titles are all good things. If the board can show enough self restraint to limit its scope to such clarifications and can refrain from the equivalent of “judicial activism” then I can support these efforts.
I will further note that I am frustrated by the repeated claims that “it is just a draft”. At some point, once things have been this way not just for minutes, hours, days, or even weeks, but months and months, bordering on years — and after surviving extensive discussions — well, at some point one can safely assume that things that have survived to this point are a fair indication of things to come.
Sam, I was not aware of dc:creator being in the RSS 2.0 at some point. It was not there when I wrote the post. Was it in a draft version?
dc:creator predated RSS 2.0.
On 9/18/02, RSS 2.0 was no longer draft. It continued to be updated. Some of these updates were publicly noted. Others were not.
On 10/1/02, the “official” RSS 2.0 specification prominently linked to an example which made use of dc:creator. This example was based on a MovableType template that Dave Winer praised.
By June 2003, all this was forgotten, as he references had long ago been purged from the “official” (and allegedly "stable") document. People who had followed the previously sanctioned advice were now called names.
The draft spec was proposed for a vote on RSS-Board not long ago and died for lack of a second. How can that be regarded as a sign it’s likely to be approved at some point? I am, to date, the only board member to publicly advocate its adoption.
The draft spec was proposed for a vote on RSS-Board not long ago and died for lack of a second. How can that be regarded as a sign it’s likely to be approved at some point? I am, to date, the only board member to publicly advocate its adoption.
You brought up the example of how many enclosures can an item have. So let me turn the question around: how long has the existing RSS Board been aware of that exact issue? How much longer do you expect the process to take?
I think the answers to those questions would prove most helpful in answering the question you actually posed, namely “who should address it?”.
Meanwhile, it looks like the IETF is going to have fun resolving the issue of dueling canonical references for the RSS 2.0 specification.
I expect the RSS profile will take around 30-45 days to complete and propose to a vote. The profile can’t solve problems in RSS, but it can identify and attempt to mitigate them.
As for the draft spec, I don’t know, but I would support other means to solve these four outstanding issues with RSS 2.0:
1. How many enclosures can an item contain?
2. Can HTML be used outside of item descriptions?
3. How do you resolve relative URLs?
4. Can core elements be extended with namespace attributes?
If Dave Winer answered these questions definitively and urged his interpretation to be treated as valid RSS, I think the board would gladly follow his lead.
Spending the day in Rails tutorial-land. Genetics Dot Net Two - Adaptive Programming - Experimenting with genetic programming in C#. NDemo - Tool to create automated testable demonstration software. (via Roy Osherove ) AForge.NET open source...
Can I state for the record that I don’t understand this sentiment: So, the RSS spec already IS being changed. The big companies are in charge and we’ve gotta deal with any mess they get together and create for all of us. For one, Scoble, have you...