- Some members of the RSS community want to introduce an element
content:encoded in an appendix to the RSS specification that we are
working on. I'd like to hear from the board members, if this stands
any chance of getting adopted.
My personal belief is that introducing new elements to the RSS
specification (even in an appendix) is outside of our charter and
does not respect the roadmap.
Roadmap: We anticipate possible 2.0.2 or 2.0.3 versions, etc. only
for the purpose of clarifying the specification, not for adding new
features to the format.
I've also heard similar reluctance voiced here.
Meg Hourihan: I did not think it meant changing the spec
(e.g. adding new elements, removing un-used elements, etc.).
This is not a binding vote, just an attempt to determine the will of
the board and you can choose to simply ignore this. Please respond
either "yes, I'm in favor of adding extensions to an appendix of the
spec" or "no, I'm no in favor of adding extensions to an appendix of
the spec" or "abstain".
- --- In firstname.lastname@example.org, "Randy Morin" <randy@...> wrote:
> My personal belief is that introducing new elements to the RSSI'm withholding judgment on the idea until I can float a draft page
> specification (even in an appendix) is outside of our charter and
> does not respect the roadmap.
for review on RSS-Public and see what people think. I can't tell
whether it's a good or bad idea yet.
I would like to find some way on rssboard.org to promote the most
useful namespaced elements.
There is precedent for supplementing the spec with additional
documentation. The skipHours/skipDays and encoding examples pages are
both linked from RSS 2.0.1-rv.6 and several preceding versions:
The RSSCloud interface also is documented separately: