I think it's time that the board answered them.
In February, work began on a new, written-from-scratch draft of the specification, with each revision announced and vetted on the RSS-Public mailing list. The main contributors to the draft are four members of the board and one of the lead developers of the Feed Validator: James Holderness, Randy Charles Morin, Sam Ruby, Greg Smith and myself.
The new draft documents the same elements and attributes described in RSS 2.0 (version 2.0.8), the current spec, making no changes to the requirements upon which RSS creators Dan Libby and Dave Winer sparked the incredibly successful RSS boom. No elements have been added or removed.
It does clarify the RSS specification in the three areas mentioned above, based on our interpretation of the current spec and its predecessors:
Though we could answer these three questions by editing the current spec, this draft should be easier to interpret because it follows the rules of RFC 2119, a standard for spec writers that dictates exactly what words like "must", "may" and "should" mean when they appear in a technical document.
It also has been through a thorough and open review process that included 11 revisions to the draft and 13 revisions to a companion document still under development, the RSS Profile.
I proposed today that the RSS Advisory Board adopt the draft as version 2.0.9 of the RSS 2.0 specification.
If this proposal is seconded, the seven-day discussion period will be used to fix mistakes, address concerns and make other minor edits to this draft. When the vote begins, I'll report to the board on the changes that were made and publish the final draft at the above URL for consideration.
Comments from the public are encouraged on the RSS-Public mailing list.
Rogers,
Having been out of the techie end of IT for sometime now (and then only on the big iron when I was), I have a confession to make. I've been fascinated following the comings and goings towards you and the team working up the RSS spec you occasionally relate on your weblog.
"In the old days" you cracked your messages and codes manual and were thrilled when some troll deep within IBM had brought down new descriptions to your favourite ways to kill a batch job. You developed a sense of smell for why something went bump in the night. You relished the overtime the pager represented when something did.
These days folks like yourself have wrenched the thunderbolts directly from the hands of Thor and wielded them with clarity and agility. Oh that we could have had that kind of influence back then.
To be frank however, you do have an advantage. The printing press had only just been invented (and IBM must have held the patent given the amount they committed to paper). We had to shoo baby dinosaurs out of the manuals library all the time before finding a comfy spot against some DASD on the raised floor, cracking open the Autocoder manual to understand how "bump" became "dump". None of this pina colada coding standards stuff for us. And we liked it.
Beware programmers bearing screwdrivers and remember to always pop your stacks.
Well done.
Regards,
etc.
All comments are moderated before publication. These HTML tags are permitted: <p>, <b>, <i>, <a>, and <blockquote>. This site is protected by reCAPTCHA (for which the Google Privacy Policy and Terms of Service apply).