Our discussion period on these edit is complete. Rogers, can you summarize the
edits in one post and we will begin a voting period.
Thanks,

Randy


--- In rss-board@yahoogroups.com, "rcade" <cadenhead@...> wrote:
>
> --- In rss-board@yahoogroups.com, "scamden" <sterling@> wrote:
> > In favor.  I don't see why this was separate to begin with.  Was it
> > expected to be expanded?
>
> I don't think so -- the elements are pretty simple and I can't recall any
consideration of making them more complex.
>
> With Sterling's second, the proposal is now for six edits. We will discuss
them for seven days and then begin the vote on March 19.
>

Today begins the seven-day vote on the six proposed admin edits to the RSS spec.

I've restated the proposal in full here:

I'd like the board to consider some administrative changes that have been
long-needed on the RSS 2.0 specification. These edits have no implications to
the elements and attributes that make up the RSS format.

I'd like the board to adopt all of the following six edits to the spec:

1. The spec, unlike the RSS Profile, does not contain a link to the Feed
Validator. I'd like to add this sentence to the About a Document [1] section:
"RSS documents can be tested for validity in the RSS Validator [2]."

2. The About the Document section contains two incorrect statements: "This
document represents the status of RSS as of the Fall of 2002, version 2.0.1. It
incorporates all changes and additions, starting with the basic spec for RSS
0.91 (June 2000) and includes new features introduced in RSS 0.92 (December
2000) and RSS 0.94 (August 2002)."

The reference to RSS 0.94 is incorrect -- that version was withdrawn right after
publication and renumbered as RSS 2.0. Also, the Fall 2002 date and 2.0.1
version number are seven years out of date. The current document version number
and publication date are identified in the Archivist's Note atop the
specification.

I'd like to change these two paragraphs to the single sentence "This document
represents the current status of RSS, incorporating all changes and additions
starting with the basic spec for RSS 0.91 (June 2000) and follows RSS 0.92
(December 2000), RSS 2.0 (August 2002), and RSS 2.0.1 (July 2003)." Each of the
old specs on rssboard.org would be linked in the paragraph.

3. In the Enclosure section [3], the use case for the element is not hosted at
rssboard.org and is intermittently unavailable or slow due to server crashes.
I'd like to change the link to a locally hosted copy of the use case document at
[4]. We're already doing this for other documentation required by the
specification in the cloud [5] and item [6] sections.

4. The Comments section [7] also links to an external document required by the
spec. I'd like to change the link to a locally hosted copy of the document at
[8].

5. The ttl section [9] contains a link to Gnutella that has been broken for
years. I'd like to remove this link.

6. The definitions for skipHours and skipDays in the supporting document [10]
are extremely short. I'd like to bring them into the specification's optional
channel elements section [11] by replacing "More info here" with the
definitions.

skipHours becomes "A hint for aggregators telling them which hours they can
skip. This element contains up to 24 <hour> sub-elements whose value is a number
between 0 and 23, representing a time in GMT, when aggregators, if they support
the feature, may not read the channel on hours listed in the skipHours element.
The hour beginning at midnight is hour zero."

skipDays becomes "A hint for aggregators telling them which days they can skip.
This element contains up to seven <day> sub-elements whose value is Monday,
Tuesday, Wednesday, Thursday, Friday, Saturday or Sunday. Aggregators may not
read the channel during days listed in the skipDays element."

The only change I made in copying the definitions over is changing "An XML
element" to "This element". No elements in the spec are defined by calling them
"XML elements."

1: http://www.rssboard.org/rss-specification#aboutThisDocument
2: http://www.rssboard.org/rss-validator
3: http://www.rssboard.org/rss-specification#ltenclosuregtSubelementOfLtitemgt
4: http://www.rssboard.org/rss-enclosures-use-case
5: http://www.rssboard.org/rss-specification#ltcloudgtSubelementOfLtchannelgt
6: http://www.rssboard.org/rss-specification#hrelementsOfLtitemgt
7: http://www.rssboard.org/rss-specification#hrelementsOfLtitemgt
8: http://www.rssboard.org/rss-weblog-comments-use-case
9: http://www.rssboard.org/rss-specification#ltttlgtSubelementOfLtchannelgt
10: http://www.rssboard.org/skip-hours-days
11: http://www.rssboard.org/rss-specification#optionalChannelElements

I vote +1 for these changes.

Thanks,

Paul

On Fri, Mar 20, 2009 at 11:02 AM, rcade <cadenhead@...> wrote:
> Today begins the seven-day vote on the six proposed admin edits to the RSS
spec.
>
> I've restated the proposal in full here:
>
> I'd like the board to consider some administrative changes that have been
long-needed on the RSS 2.0 specification. These edits have no implications to
the elements and attributes that make up the RSS format.
>
> I'd like the board to adopt all of the following six edits to the spec:
>
> 1. The spec, unlike the RSS Profile, does not contain a link to the Feed
Validator. I'd like to add this sentence to the About a Document [1] section:
"RSS documents can be tested for validity in the RSS Validator [2]."
>
> 2. The About the Document section contains two incorrect statements: "This
document represents the status of RSS as of the Fall of 2002, version 2.0.1. It
incorporates all changes and additions, starting with the basic spec for RSS
0.91 (June 2000) and includes new features introduced in RSS 0.92 (December
2000) and RSS 0.94 (August 2002)."
>
> The reference to RSS 0.94 is incorrect -- that version was withdrawn right
after publication and renumbered as RSS 2.0. Also, the Fall 2002 date and 2.0.1
version number are seven years out of date. The current document version number
and publication date are identified in the Archivist's Note atop the
specification.
>
> I'd like to change these two paragraphs to the single sentence "This document
represents the current status of RSS, incorporating all changes and additions
starting with the basic spec for RSS 0.91 (June 2000) and follows RSS 0.92
(December 2000), RSS 2.0 (August 2002), and RSS 2.0.1 (July 2003)." Each of the
old specs on rssboard.org would be linked in the paragraph.
>
> 3. In the Enclosure section [3], the use case for the element is not hosted at
rssboard.org and is intermittently unavailable or slow due to server crashes.
I'd like to change the link to a locally hosted copy of the use case document at
[4]. We're already doing this for other documentation required by the
specification in the cloud [5] and item [6] sections.
>
> 4. The Comments section [7] also links to an external document required by the
spec. I'd like to change the link to a locally hosted copy of the document at
[8].
>
> 5. The ttl section [9] contains a link to Gnutella that has been broken for
years. I'd like to remove this link.
>
> 6. The definitions for skipHours and skipDays in the supporting document [10]
are extremely short. I'd like to bring them into the specification's optional
channel elements section [11] by replacing "More info here" with the
definitions.
>
> skipHours becomes "A hint for aggregators telling them which hours they can
skip. This element contains up to 24 <hour> sub-elements whose value is a number
between 0 and 23, representing a time in GMT, when aggregators, if they support
the feature, may not read the channel on hours listed in the skipHours element.
The hour beginning at midnight is hour zero."
>
> skipDays becomes "A hint for aggregators telling them which days they can
skip. This element contains up to seven <day> sub-elements whose value is
Monday, Tuesday, Wednesday, Thursday, Friday, Saturday or Sunday. Aggregators
may not read the channel during days listed in the skipDays element."
>
> The only change I made in copying the definitions over is changing "An XML
element" to "This element". No elements in the spec are defined by calling them
"XML elements."
>
> 1: http://www.rssboard.org/rss-specification#aboutThisDocument
> 2: http://www.rssboard.org/rss-validator
> 3: http://www.rssboard.org/rss-specification#ltenclosuregtSubelementOfLtitemgt
> 4: http://www.rssboard.org/rss-enclosures-use-case
> 5: http://www.rssboard.org/rss-specification#ltcloudgtSubelementOfLtchannelgt
> 6: http://www.rssboard.org/rss-specification#hrelementsOfLtitemgt
> 7: http://www.rssboard.org/rss-specification#hrelementsOfLtitemgt
> 8: http://www.rssboard.org/rss-weblog-comments-use-case
> 9: http://www.rssboard.org/rss-specification#ltttlgtSubelementOfLtchannelgt
> 10: http://www.rssboard.org/skip-hours-days
> 11: http://www.rssboard.org/rss-specification#optionalChannelElements
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

I vote in favor of all of these proposed edits.

--- In rss-board@yahoogroups.com, "rcade" <cadenhead@...> wrote:
>
> Today begins the seven-day vote on the six proposed admin edits to the RSS
spec.
>
> I've restated the proposal in full here:
>
> I'd like the board to consider some administrative changes that have been
long-needed on the RSS 2.0 specification. These edits have no implications to
the elements and attributes that make up the RSS format.
>
> I'd like the board to adopt all of the following six edits to the spec:
>
> 1. The spec, unlike the RSS Profile, does not contain a link to the Feed
Validator. I'd like to add this sentence to the About a Document [1] section:
"RSS documents can be tested for validity in the RSS Validator [2]."
>
> 2. The About the Document section contains two incorrect statements: "This
document represents the status of RSS as of the Fall of 2002, version 2.0.1. It
incorporates all changes and additions, starting with the basic spec for RSS
0.91 (June 2000) and includes new features introduced in RSS 0.92 (December
2000) and RSS 0.94 (August 2002)."
>
> The reference to RSS 0.94 is incorrect -- that version was withdrawn right
after publication and renumbered as RSS 2.0. Also, the Fall 2002 date and 2.0.1
version number are seven years out of date. The current document version number
and publication date are identified in the Archivist's Note atop the
specification.
>
> I'd like to change these two paragraphs to the single sentence "This document
represents the current status of RSS, incorporating all changes and additions
starting with the basic spec for RSS 0.91 (June 2000) and follows RSS 0.92
(December 2000), RSS 2.0 (August 2002), and RSS 2.0.1 (July 2003)." Each of the
old specs on rssboard.org would be linked in the paragraph.
>
> 3. In the Enclosure section [3], the use case for the element is not hosted at
rssboard.org and is intermittently unavailable or slow due to server crashes.
I'd like to change the link to a locally hosted copy of the use case document at
[4]. We're already doing this for other documentation required by the
specification in the cloud [5] and item [6] sections.
>
> 4. The Comments section [7] also links to an external document required by the
spec. I'd like to change the link to a locally hosted copy of the document at
[8].
>
> 5. The ttl section [9] contains a link to Gnutella that has been broken for
years. I'd like to remove this link.
>
> 6. The definitions for skipHours and skipDays in the supporting document [10]
are extremely short. I'd like to bring them into the specification's optional
channel elements section [11] by replacing "More info here" with the
definitions.
>
> skipHours becomes "A hint for aggregators telling them which hours they can
skip. This element contains up to 24 <hour> sub-elements whose value is a number
between 0 and 23, representing a time in GMT, when aggregators, if they support
the feature, may not read the channel on hours listed in the skipHours element.
The hour beginning at midnight is hour zero."
>
> skipDays becomes "A hint for aggregators telling them which days they can
skip. This element contains up to seven <day> sub-elements whose value is
Monday, Tuesday, Wednesday, Thursday, Friday, Saturday or Sunday. Aggregators
may not read the channel during days listed in the skipDays element."
>
> The only change I made in copying the definitions over is changing "An XML
element" to "This element". No elements in the spec are defined by calling them
"XML elements."
>
> 1: http://www.rssboard.org/rss-specification#aboutThisDocument
> 2: http://www.rssboard.org/rss-validator
> 3: http://www.rssboard.org/rss-specification#ltenclosuregtSubelementOfLtitemgt
> 4: http://www.rssboard.org/rss-enclosures-use-case
> 5: http://www.rssboard.org/rss-specification#ltcloudgtSubelementOfLtchannelgt
> 6: http://www.rssboard.org/rss-specification#hrelementsOfLtitemgt
> 7: http://www.rssboard.org/rss-specification#hrelementsOfLtitemgt
> 8: http://www.rssboard.org/rss-weblog-comments-use-case
> 9: http://www.rssboard.org/rss-specification#ltttlgtSubelementOfLtchannelgt
> 10: http://www.rssboard.org/skip-hours-days
> 11: http://www.rssboard.org/rss-specification#optionalChannelElements
>

+1

--
Ryan Parman
<http://ryanparman.com>




On Mar 20, 2009, at 4:41 PM, "scamden" <sterling@...>
wrote:

> I vote in favor of all of these proposed edits.
>
> --- In rss-board@yahoogroups.com, "rcade" <cadenhead@...> wrote:
>>
>> Today begins the seven-day vote on the six proposed admin edits to
>> the RSS spec.
>>
>> I've restated the proposal in full here:
>>
>> I'd like the board to consider some administrative changes that
>> have been long-needed on the RSS 2.0 specification. These edits
>> have no implications to the elements and attributes that make up
>> the RSS format.
>>
>> I'd like the board to adopt all of the following six edits to the
>> spec:
>>
>> 1. The spec, unlike the RSS Profile, does not contain a link to the
>> Feed Validator. I'd like to add this sentence to the About a
>> Document [1] section: "RSS documents can be tested for validity in
>> the RSS Validator [2]."
>>
>> 2. The About the Document section contains two incorrect
>> statements: "This document represents the status of RSS as of the
>> Fall of 2002, version 2.0.1. It incorporates all changes and
>> additions, starting with the basic spec for RSS 0.91 (June 2000)
>> and includes new features introduced in RSS 0.92 (December 2000)
>> and RSS 0.94 (August 2002)."
>>
>> The reference to RSS 0.94 is incorrect -- that version was
>> withdrawn right after publication and renumbered as RSS 2.0. Also,
>> the Fall 2002 date and 2.0.1 version number are seven years out of
>> date. The current document version number and publication date are
>> identified in the Archivist's Note atop the specification.
>>
>> I'd like to change these two paragraphs to the single sentence
>> "This document represents the current status of RSS, incorporating
>> all changes and additions starting with the basic spec for RSS 0.91
>> (June 2000) and follows RSS 0.92 (December 2000), RSS 2.0 (August
>> 2002), and RSS 2.0.1 (July 2003)." Each of the old specs on
>> rssboard.org would be linked in the paragraph.
>>
>> 3. In the Enclosure section [3], the use case for the element is
>> not hosted at rssboard.org and is intermittently unavailable or
>> slow due to server crashes. I'd like to change the link to a
>> locally hosted copy of the use case document at [4]. We're already
>> doing this for other documentation required by the specification in
>> the cloud [5] and item [6] sections.
>>
>> 4. The Comments section [7] also links to an external document
>> required by the spec. I'd like to change the link to a locally
>> hosted copy of the document at [8].
>>
>> 5. The ttl section [9] contains a link to Gnutella that has been
>> broken for years. I'd like to remove this link.
>>
>> 6. The definitions for skipHours and skipDays in the supporting
>> document [10] are extremely short. I'd like to bring them into the
>> specification's optional channel elements section [11] by replacing
>> "More info here" with the definitions.
>>
>> skipHours becomes "A hint for aggregators telling them which hours
>> they can skip. This element contains up to 24 <hour> sub-elements
>> whose value is a number between 0 and 23, representing a time in
>> GMT, when aggregators, if they support the feature, may not read
>> the channel on hours listed in the skipHours element. The hour
>> beginning at midnight is hour zero."
>>
>> skipDays becomes "A hint for aggregators telling them which days
>> they can skip. This element contains up to seven <day> sub-elements
>> whose value is Monday, Tuesday, Wednesday, Thursday, Friday,
>> Saturday or Sunday. Aggregators may not read the channel during
>> days listed in the skipDays element."
>>
>> The only change I made in copying the definitions over is changing
>> "An XML element" to "This element". No elements in the spec are
>> defined by calling them "XML elements."
>>
>> 1: http://www.rssboard.org/rss-specification#aboutThisDocument
>> 2: http://www.rssboard.org/rss-validator
>> 3:
http://www.rssboard.org/rss-specification#ltenclosuregtSubelementOfLtitemgt
>> 4: http://www.rssboard.org/rss-enclosures-use-case
>> 5: http://www.rssboard.org/rss-specification#ltcloudgtSubelementOfLtchannelgt
>> 6: http://www.rssboard.org/rss-specification#hrelementsOfLtitemgt
>> 7: http://www.rssboard.org/rss-specification#hrelementsOfLtitemgt
>> 8: http://www.rssboard.org/rss-weblog-comments-use-case
>> 9: http://www.rssboard.org/rss-specification#ltttlgtSubelementOfLtchannelgt
>> 10: http://www.rssboard.org/skip-hours-days
>> 11: http://www.rssboard.org/rss-specification#optionalChannelElements
>>
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

I vote yes for the proposal.

rcade:
> The only change I made in copying the definitions over is changing
> "An XML element" to "This element". No elements in the spec are
> defined by calling them "XML elements."

In the interests of completeness, I noticed another difference between the
two versions of the enclosure use-case document:
http://www.thetwowayweb.com/payloadsforrss
http://www.rssboard.org/rss-enclosures-use-case

The last line of the document changed from:
   "SOAP meets RSS describes a publish-and-subscribe notification system..."
to
   "The RSSCloud Interface, a publish-and-subscribe notification system..."

They link to different locations too.

That said, I'm still in favour of these changes.

Regards
James

I vote in favor of the edits


--- In rss-board@yahoogroups.com, "rcade" <cadenhead@...> wrote:
>
> Today begins the seven-day vote on the six proposed admin edits to the RSS
spec.
>
> I've restated the proposal in full here:
>
> I'd like the board to consider some administrative changes that have been
long-needed on the RSS 2.0 specification. These edits have no implications to
the elements and attributes that make up the RSS format.
>
> I'd like the board to adopt all of the following six edits to the spec:
>
> 1. The spec, unlike the RSS Profile, does not contain a link to the Feed
Validator. I'd like to add this sentence to the About a Document [1] section:
"RSS documents can be tested for validity in the RSS Validator [2]."
>
> 2. The About the Document section contains two incorrect statements: "This
document represents the status of RSS as of the Fall of 2002, version 2.0.1. It
incorporates all changes and additions, starting with the basic spec for RSS
0.91 (June 2000) and includes new features introduced in RSS 0.92 (December
2000) and RSS 0.94 (August 2002)."
>
> The reference to RSS 0.94 is incorrect -- that version was withdrawn right
after publication and renumbered as RSS 2.0. Also, the Fall 2002 date and 2.0.1
version number are seven years out of date. The current document version number
and publication date are identified in the Archivist's Note atop the
specification.
>
> I'd like to change these two paragraphs to the single sentence "This document
represents the current status of RSS, incorporating all changes and additions
starting with the basic spec for RSS 0.91 (June 2000) and follows RSS 0.92
(December 2000), RSS 2.0 (August 2002), and RSS 2.0.1 (July 2003)." Each of the
old specs on rssboard.org would be linked in the paragraph.
>
> 3. In the Enclosure section [3], the use case for the element is not hosted at
rssboard.org and is intermittently unavailable or slow due to server crashes.
I'd like to change the link to a locally hosted copy of the use case document at
[4]. We're already doing this for other documentation required by the
specification in the cloud [5] and item [6] sections.
>
> 4. The Comments section [7] also links to an external document required by the
spec. I'd like to change the link to a locally hosted copy of the document at
[8].
>
> 5. The ttl section [9] contains a link to Gnutella that has been broken for
years. I'd like to remove this link.
>
> 6. The definitions for skipHours and skipDays in the supporting document [10]
are extremely short. I'd like to bring them into the specification's optional
channel elements section [11] by replacing "More info here" with the
definitions.
>
> skipHours becomes "A hint for aggregators telling them which hours they can
skip. This element contains up to 24 <hour> sub-elements whose value is a number
between 0 and 23, representing a time in GMT, when aggregators, if they support
the feature, may not read the channel on hours listed in the skipHours element.
The hour beginning at midnight is hour zero."
>
> skipDays becomes "A hint for aggregators telling them which days they can
skip. This element contains up to seven <day> sub-elements whose value is
Monday, Tuesday, Wednesday, Thursday, Friday, Saturday or Sunday. Aggregators
may not read the channel during days listed in the skipDays element."
>
> The only change I made in copying the definitions over is changing "An XML
element" to "This element". No elements in the spec are defined by calling them
"XML elements."
>
> 1: http://www.rssboard.org/rss-specification#aboutThisDocument
> 2: http://www.rssboard.org/rss-validator
> 3: http://www.rssboard.org/rss-specification#ltenclosuregtSubelementOfLtitemgt
> 4: http://www.rssboard.org/rss-enclosures-use-case
> 5: http://www.rssboard.org/rss-specification#ltcloudgtSubelementOfLtchannelgt
> 6: http://www.rssboard.org/rss-specification#hrelementsOfLtitemgt
> 7: http://www.rssboard.org/rss-specification#hrelementsOfLtitemgt
> 8: http://www.rssboard.org/rss-weblog-comments-use-case
> 9: http://www.rssboard.org/rss-specification#ltttlgtSubelementOfLtchannelgt
> 10: http://www.rssboard.org/skip-hours-days
> 11: http://www.rssboard.org/rss-specification#optionalChannelElements
>

All the amendments are approved.

Voting Results were 7-0 in favor.

For: Querna,Camdem,Parman,Cadenhead,Holderness,Carletti,Morin
Against: none
Didn't vote: Lunt,Levine,Shellen,Savin


--- In rss-board@yahoogroups.com, "rcade" <cadenhead@...> wrote:
>
> Today begins the seven-day vote on the six proposed admin edits to the RSS
spec.
>
> I've restated the proposal in full here:
>
> I'd like the board to consider some administrative changes that have been
long-needed on the RSS 2.0 specification. These edits have no implications to
the elements and attributes that make up the RSS format.
>
> I'd like the board to adopt all of the following six edits to the spec:
>
> 1. The spec, unlike the RSS Profile, does not contain a link to the Feed
Validator. I'd like to add this sentence to the About a Document [1] section:
"RSS documents can be tested for validity in the RSS Validator [2]."
>
> 2. The About the Document section contains two incorrect statements: "This
document represents the status of RSS as of the Fall of 2002, version 2.0.1. It
incorporates all changes and additions, starting with the basic spec for RSS
0.91 (June 2000) and includes new features introduced in RSS 0.92 (December
2000) and RSS 0.94 (August 2002)."
>
> The reference to RSS 0.94 is incorrect -- that version was withdrawn right
after publication and renumbered as RSS 2.0. Also, the Fall 2002 date and 2.0.1
version number are seven years out of date. The current document version number
and publication date are identified in the Archivist's Note atop the
specification.
>
> I'd like to change these two paragraphs to the single sentence "This document
represents the current status of RSS, incorporating all changes and additions
starting with the basic spec for RSS 0.91 (June 2000) and follows RSS 0.92
(December 2000), RSS 2.0 (August 2002), and RSS 2.0.1 (July 2003)." Each of the
old specs on rssboard.org would be linked in the paragraph.
>
> 3. In the Enclosure section [3], the use case for the element is not hosted at
rssboard.org and is intermittently unavailable or slow due to server crashes.
I'd like to change the link to a locally hosted copy of the use case document at
[4]. We're already doing this for other documentation required by the
specification in the cloud [5] and item [6] sections.
>
> 4. The Comments section [7] also links to an external document required by the
spec. I'd like to change the link to a locally hosted copy of the document at
[8].
>
> 5. The ttl section [9] contains a link to Gnutella that has been broken for
years. I'd like to remove this link.
>
> 6. The definitions for skipHours and skipDays in the supporting document [10]
are extremely short. I'd like to bring them into the specification's optional
channel elements section [11] by replacing "More info here" with the
definitions.
>
> skipHours becomes "A hint for aggregators telling them which hours they can
skip. This element contains up to 24 <hour> sub-elements whose value is a number
between 0 and 23, representing a time in GMT, when aggregators, if they support
the feature, may not read the channel on hours listed in the skipHours element.
The hour beginning at midnight is hour zero."
>
> skipDays becomes "A hint for aggregators telling them which days they can
skip. This element contains up to seven <day> sub-elements whose value is
Monday, Tuesday, Wednesday, Thursday, Friday, Saturday or Sunday. Aggregators
may not read the channel during days listed in the skipDays element."
>
> The only change I made in copying the definitions over is changing "An XML
element" to "This element". No elements in the spec are defined by calling them
"XML elements."
>
> 1: http://www.rssboard.org/rss-specification#aboutThisDocument
> 2: http://www.rssboard.org/rss-validator
> 3: http://www.rssboard.org/rss-specification#ltenclosuregtSubelementOfLtitemgt
> 4: http://www.rssboard.org/rss-enclosures-use-case
> 5: http://www.rssboard.org/rss-specification#ltcloudgtSubelementOfLtchannelgt
> 6: http://www.rssboard.org/rss-specification#hrelementsOfLtitemgt
> 7: http://www.rssboard.org/rss-specification#hrelementsOfLtitemgt
> 8: http://www.rssboard.org/rss-weblog-comments-use-case
> 9: http://www.rssboard.org/rss-specification#ltttlgtSubelementOfLtchannelgt
> 10: http://www.rssboard.org/skip-hours-days
> 11: http://www.rssboard.org/rss-specification#optionalChannelElements
>

As you probably know, Dave Winer's been working to revive the cloud element in
RSS and the RSSCloud Interface that defines how it is used. These date back to
RSS 0.92. The work's described on a web site he has launched:

http://www.rsscloud.org/

For this effort, Winer is unilaterally making changes to the RSSCloud Interface.
He has added multiple url# arguments (url1, url2, url3 and so on) to the REST
interface:

http://rsscloud.org/walkthrough.html#requestingNotificationUsingRest

He also has added a REST ping method:

http://rsscloud.org/walkthrough.html#pingingViaRestaNamepingresta

WordPress has implemented RSSCloud with Winer's participation for all seven
million of its hosted blogs on wordpress.com.

I'd like to know what the members think that the RSS Advisory Board should do,
if anything, in regard to this effort. I've posted the same question on the
RSS-Public mailing list.

I've written my thoughts on the subject on my blog.

http://workbench.cadenhead.org/news/3559

The short version is that one person should not be allowed to control the
revision of the RSSCloud Interface.

You've pretty much summed up my feelings on it.  I think this is a
responsibility that the Board should take on.  I do think that Winer's changes
have merit, but we need to make sure that they're well specified before they get
implemented by so many people that they're forever deadlocked in murkiness for
compatibility's sake.

--- In rss-board@yahoogroups.com, "rcade" <cadenhead@...> wrote:
>
> I've written my thoughts on the subject on my blog.
>
> http://workbench.cadenhead.org/news/3559
>
> The short version is that one person should not be allowed to control the
revision of the RSSCloud Interface.
>

On Tue, Sep 15, 2009 at 1:53 PM, rcade <cadenhead@...> wrote:
> I've written my thoughts on the subject on my blog.
>
> http://workbench.cadenhead.org/news/3559
>
> The short version is that one person should not be allowed to control the
revision of the RSSCloud Interface.

I agree that the process of creating a spec unilaterally by a single
(or even small group of people!) is not a good thing.

I don't believe 'we' as the RSS Board should 'take over' anything though.

I personally believe the only thing the RSS Board should perhaps do,
is promote PubSubHubBub, it is being developed in the open, by people
who get it. (once they are approaching a finalized specification of
course)

That should be our response, not diving into political games that
poison communities.

As Brad mentioned in his blog post, It is unfortunate that there was
some belief that PubSubHubBub is specific to Atom -- but that has been
corrected, and was just an oversight.

--- In rss-public@yahoogroups.com, "James Holderness" <j4_james@...> wrote:
> Let's leave Dave to do his thing for now. Offer feedback if you
> think it might help (some of his changes do seem to be in response
> to comments others have made), and once the technology has matured
> and is more widely used, we can consider whether further action
> from the board would helpful.

If we defer to Dave, he will control RSSCloud and the most likely outcome is
that the spec will be imprecise, he will declare it frozen and we won't be in
any position to do anything afterward other than live with it. RSS includes
RSSCloud, so the RSS Advisory Board will be tasked with helping people support
it.

If we are letting him take over a component of the RSS specification and make
changes to it, I think the board members who favor this course should get
involved with his development of RSSCloud before he declares it frozen. The
window of opportunity to improve it is probably short.

Also, I think the new RSSCloud needs a version number to distinguish it from the
original interface.

Dave has made a request to me that could be directed to the board as well:

"A couple of requests.

"1. Work through the rsscloud.org doc with the same approach you used here. An
open mind, don't prejudge. I'd be interested to hear how your experience
compares.

"2. Review the docs and report any problems you see. There's a mail list or use
the comments section on the walkthrough. As you've said, now is the time to fix
problems. If you find them later it will be more difficult.

"3. Also if possible review the Wordpress implementation and my rsscloud.root. I
shipped source and it's in a Frontier tool, an environment you know well."

I appreciate the gesture he's made here, but speaking for myself personally, I
won't participate in a project that puts part of RSS in a single developer's
control. We fought hard to establish a public process and community
decision-making on matters related to RSS, and supporting his project is counter
to that.

IMHO, I don't understand how anybody thinks that rssCloud could possibly work.
There's simply too many scenarios where the spec fails.

See scenarios of failure
http://www.therssweblog.com/?guid=20090916100620

Unless there is major changes to address these holes, then I'm not really
prepared to put any time into it.

Thanks,

Randy

--- In rss-board@yahoogroups.com, "rcade" <cadenhead@...> wrote:
>
> As you probably know, Dave Winer's been working to revive the cloud element in
RSS and the RSSCloud Interface that defines how it is used. These date back to
RSS 0.92. The work's described on a web site he has launched:
>
> http://www.rsscloud.org/
>
> For this effort, Winer is unilaterally making changes to the RSSCloud
Interface. He has added multiple url# arguments (url1, url2, url3 and so on) to
the REST interface:
>
> http://rsscloud.org/walkthrough.html#requestingNotificationUsingRest
>
> He also has added a REST ping method:
>
> http://rsscloud.org/walkthrough.html#pingingViaRestaNamepingresta
>
> WordPress has implemented RSSCloud with Winer's participation for all seven
million of its hosted blogs on wordpress.com.
>
> I'd like to know what the members think that the RSS Advisory Board should do,
if anything, in regard to this effort. I've posted the same question on the
RSS-Public mailing list.
>

The RSS Advisory Board is now running a local copy of the Feed Validator:

http://rssboard.org/rss-validator

I'm still making some adjustments to the presentation, but it looks like it
works properly. If you could test it with your own RSS feeds and let me know if
you encounter problems, that would be helpful.

The validator didn't have a "valid RSS" badge that includes the Feed Icon, so I
created one:

http://rssboard.org/rss-validator/images/valid-rss.png

I will try to keep the code up to date with the Feed Validator and contribute
any changes I make back to the project. So far it's running the exact same code.

The valid RSS badge is available for reuse under the Creative Commons
Attribution/Share Alike license [1]

1: http://creativecommons.org/licenses/by-sa/2.0/

The following RSS Advisory Board proposal has been made by Rogers Cadenhead and
seconded by Ryan Parman.

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 [1].

Media RSS [2] is a namespace for syndicating audio, video and image files that
was created by Yahoo in 2004. The namespace extends RSS support for enclosures
to enable a number of different applications, such as video and audio search
engines, multiple bitrates and encodings of the same content, artist credits and
copyright information, and the ability to play the content with a specified
media player.

In the five years since its launch, Media RSS has become highly popular with
podcasters and other multimedia publishers and fostered an active development
community at the Yahoo Groups mailing list RSS-Media [3]. The namespace is
supported by Yahoo Search, Bing, Wikipedia, Flock, Picasa, FriendFeed, Bebo and
many other sites and software.

Yahoo, with the participation of members of RSS-Media, recently published
version 1.5 of the Media RSS specification.

Over the past year, there have been discussions about the RSS Advisory Board
becoming the publisher of the Media RSS namespace to ensure its continued
availability and stability, a function the board serves for RSS 0.90 and RSS
0.91. Netscape transferred those specifications [4] to the board in November
2008.

Sapna Chandiramani, a senior engineering manager at Yahoo whose department has
responsibility for the Media RSS namespace, has indicated a willingness to have
the board take over custodianship.

I propose that the RSS Advisory Board agrees to become the custodian of the
namespace, publishing the current version at the permanent URL
http://www.rssboard.org/media-rss and archiving past versions.

Additionally, the board offers to manage the RSS-Media mailing list.

Finally, the board resolves that the namespace URI for Media RSS will remain
"http://search.yahoo.com/mrss/" for as long as it is published to ensure that
software using the namespace will continue to function properly.

1: http://groups.yahoo.com/group/rss-public
2: http://video.search.yahoo.com/mrss
3: http://tech.groups.yahoo.com/group/rss-media
4: http://www.rssboard.org/news/181/rss-090-091-moving-rss-advisory-board

It makes sense to me to have the Board as the central reference point for all
things RSS. so I'm in favor of this proposal.  I could see down the road maybe
moving the namespace URL here as well, should it ever be abandoned by yahoo --
but I agree we should leave it where it is for now, for compatibility.

--- In rss-board@yahoogroups.com, "Rogers" <cadenhead@...> wrote:
>
> The following RSS Advisory Board proposal has been made by Rogers Cadenhead
and seconded by Ryan Parman.
>
> 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 [1].
>
> Media RSS [2] is a namespace for syndicating audio, video and image files that
was created by Yahoo in 2004. The namespace extends RSS support for enclosures
to enable a number of different applications, such as video and audio search
engines, multiple bitrates and encodings of the same content, artist credits and
copyright information, and the ability to play the content with a specified
media player.
>
> In the five years since its launch, Media RSS has become highly popular with
podcasters and other multimedia publishers and fostered an active development
community at the Yahoo Groups mailing list RSS-Media [3]. The namespace is
supported by Yahoo Search, Bing, Wikipedia, Flock, Picasa, FriendFeed, Bebo and
many other sites and software.
>
> Yahoo, with the participation of members of RSS-Media, recently published
version 1.5 of the Media RSS specification.
>
> Over the past year, there have been discussions about the RSS Advisory Board
becoming the publisher of the Media RSS namespace to ensure its continued
availability and stability, a function the board serves for RSS 0.90 and RSS
0.91. Netscape transferred those specifications [4] to the board in November
2008.
>
> Sapna Chandiramani, a senior engineering manager at Yahoo whose department has
responsibility for the Media RSS namespace, has indicated a willingness to have
the board take over custodianship.
>
> I propose that the RSS Advisory Board agrees to become the custodian of the
namespace, publishing the current version at the permanent URL
http://www.rssboard.org/media-rss and archiving past versions.
>
> Additionally, the board offers to manage the RSS-Media mailing list.
>
> Finally, the board resolves that the namespace URI for Media RSS will remain
"http://search.yahoo.com/mrss/" for as long as it is published to ensure that
software using the namespace will continue to function properly.
>
> 1: http://groups.yahoo.com/group/rss-public
> 2: http://video.search.yahoo.com/mrss
> 3: http://tech.groups.yahoo.com/group/rss-media
> 4: http://www.rssboard.org/news/181/rss-090-091-moving-rss-advisory-board
>

I agree both with the proposal and the suggestion to move the namespace at some
point.

What are your plans for the http://video.search.yahoo.com/mrss URL?
Will it redirect to the corresponding page on the RSS Board site?

-- Simone


--- In rss-board@yahoogroups.com, "scamden" <sterling@...> wrote:
>
> It makes sense to me to have the Board as the central reference point for all
things RSS. so I'm in favor of this proposal.  I could see down the road maybe
moving the namespace URL here as well, should it ever be abandoned by yahoo --
but I agree we should leave it where it is for now, for compatibility.
>
> --- In rss-board@yahoogroups.com, "Rogers" <cadenhead@> wrote:
> >
> > The following RSS Advisory Board proposal has been made by Rogers Cadenhead
and seconded by Ryan Parman.
> >
> > 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 [1].
> >
> > Media RSS [2] is a namespace for syndicating audio, video and image files
that was created by Yahoo in 2004. The namespace extends RSS support for
enclosures to enable a number of different applications, such as video and audio
search engines, multiple bitrates and encodings of the same content, artist
credits and copyright information, and the ability to play the content with a
specified media player.
> >
> > In the five years since its launch, Media RSS has become highly popular with
podcasters and other multimedia publishers and fostered an active development
community at the Yahoo Groups mailing list RSS-Media [3]. The namespace is
supported by Yahoo Search, Bing, Wikipedia, Flock, Picasa, FriendFeed, Bebo and
many other sites and software.
> >
> > Yahoo, with the participation of members of RSS-Media, recently published
version 1.5 of the Media RSS specification.
> >
> > Over the past year, there have been discussions about the RSS Advisory Board
becoming the publisher of the Media RSS namespace to ensure its continued
availability and stability, a function the board serves for RSS 0.90 and RSS
0.91. Netscape transferred those specifications [4] to the board in November
2008.
> >
> > Sapna Chandiramani, a senior engineering manager at Yahoo whose department
has responsibility for the Media RSS namespace, has indicated a willingness to
have the board take over custodianship.
> >
> > I propose that the RSS Advisory Board agrees to become the custodian of the
namespace, publishing the current version at the permanent URL
http://www.rssboard.org/media-rss and archiving past versions.
> >
> > Additionally, the board offers to manage the RSS-Media mailing list.
> >
> > Finally, the board resolves that the namespace URI for Media RSS will remain
"http://search.yahoo.com/mrss/" for as long as it is published to ensure that
software using the namespace will continue to function properly.
> >
> > 1: http://groups.yahoo.com/group/rss-public
> > 2: http://video.search.yahoo.com/mrss
> > 3: http://tech.groups.yahoo.com/group/rss-media
> > 4: http://www.rssboard.org/news/181/rss-090-091-moving-rss-advisory-board
> >
>

I also agree with the aforementioned proposal, but have the same question as
"wepposcarletti".

--
Ryan Parman
<http://ryanparman.com>





On Nov 26, 2009, at 12:56 AM, wepposcarletti wrote:

> I agree both with the proposal and the suggestion to move the namespace at
some point.
>
> What are your plans for the http://video.search.yahoo.com/mrss URL?
> Will it redirect to the corresponding page on the RSS Board site?
>
> -- Simone
>
>
> --- In rss-board@yahoogroups.com, "scamden" <sterling@...> wrote:
>>
>> It makes sense to me to have the Board as the central reference point for all
things RSS. so I'm in favor of this proposal.  I could see down the road maybe
moving the namespace URL here as well, should it ever be abandoned by yahoo --
but I agree we should leave it where it is for now, for compatibility.
>>
>> --- In rss-board@yahoogroups.com, "Rogers" <cadenhead@> wrote:
>>>
>>> The following RSS Advisory Board proposal has been made by Rogers Cadenhead
and seconded by Ryan Parman.
>>>
>>> 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 [1].
>>>
>>> Media RSS [2] is a namespace for syndicating audio, video and image files
that was created by Yahoo in 2004. The namespace extends RSS support for
enclosures to enable a number of different applications, such as video and audio
search engines, multiple bitrates and encodings of the same content, artist
credits and copyright information, and the ability to play the content with a
specified media player.
>>>
>>> In the five years since its launch, Media RSS has become highly popular with
podcasters and other multimedia publishers and fostered an active development
community at the Yahoo Groups mailing list RSS-Media [3]. The namespace is
supported by Yahoo Search, Bing, Wikipedia, Flock, Picasa, FriendFeed, Bebo and
many other sites and software.
>>>
>>> Yahoo, with the participation of members of RSS-Media, recently published
version 1.5 of the Media RSS specification.
>>>
>>> Over the past year, there have been discussions about the RSS Advisory Board
becoming the publisher of the Media RSS namespace to ensure its continued
availability and stability, a function the board serves for RSS 0.90 and RSS
0.91. Netscape transferred those specifications [4] to the board in November
2008.
>>>
>>> Sapna Chandiramani, a senior engineering manager at Yahoo whose department
has responsibility for the Media RSS namespace, has indicated a willingness to
have the board take over custodianship.
>>>
>>> I propose that the RSS Advisory Board agrees to become the custodian of the
namespace, publishing the current version at the permanent URL
http://www.rssboard.org/media-rss and archiving past versions.
>>>
>>> Additionally, the board offers to manage the RSS-Media mailing list.
>>>
>>> Finally, the board resolves that the namespace URI for Media RSS will remain
"http://search.yahoo.com/mrss/" for as long as it is published to ensure that
software using the namespace will continue to function properly.
>>>
>>> 1: http://groups.yahoo.com/group/rss-public
>>> 2: http://video.search.yahoo.com/mrss
>>> 3: http://tech.groups.yahoo.com/group/rss-media
>>> 4: http://www.rssboard.org/news/181/rss-090-091-moving-rss-advisory-board
>>>
>>
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

Rogers wrote:
> Finally, the board resolves that the namespace URI for Media RSS
> will remain "http://search.yahoo.com/mrss/" for as long as it is
> published to ensure that software using the namespace will
> continue to function properly.

And yet we've already had two board members suggest that it would be ok to
change the namespace URI in the future.

I would not feel comfortable having control of this specification in the
hands of the board if these members could not be persuaded to retract their
statements.

Regards
James

--- In rss-board@yahoogroups.com, "James Holderness" <j4_james@...> wrote:
> I would not feel comfortable having control of this specification in
> the hands of the board if these members could not be persuaded to
> retract their statements.

The phrase "Finally, the board resolves that the namespace URI for
Media RSS will remain "http://search.yahoo.com/mrss/" for as long as
it is published to ensure that software using the namespace will
continue to function properly." is part of the proposal. If it passes,
the board will have expressed its obligation to keep the URI unchanged
for as long as we publish the specification.

The reason this obligation is in the proposal is because changes to
the namespace URI have been an issue for the Media-RSS community in
the past.

If the proposal passes, Yahoo is going to forward its old URLs to the
documents on the RSS board web site.

Whether individual board members retract their statements seems less
relevant to me than the language of the proposal, if it passes. If we
agree collectively to keep that obligation, I think the members in the
future will keep that obligation.

Agreed.  I see no reason to retract my statement, because as long as Yahoo
continues to support the existing URL, it should remain there.

--- In rss-board@yahoogroups.com, Rogers Cadenhead <cadenhead@...> wrote:
>
> --- In rss-board@yahoogroups.com, "James Holderness" <j4_james@> wrote:
> > I would not feel comfortable having control of this specification in
> > the hands of the board if these members could not be persuaded to
> > retract their statements.
>
> The phrase "Finally, the board resolves that the namespace URI for
> Media RSS will remain "http://search.yahoo.com/mrss/" for as long as
> it is published to ensure that software using the namespace will
> continue to function properly." is part of the proposal. If it passes,
> the board will have expressed its obligation to keep the URI unchanged
> for as long as we publish the specification.
>
> The reason this obligation is in the proposal is because changes to
> the namespace URI have been an issue for the Media-RSS community in
> the past.
>
> If the proposal passes, Yahoo is going to forward its old URLs to the
> documents on the RSS board web site.
>
> Whether individual board members retract their statements seems less
> relevant to me than the language of the proposal, if it passes. If we
> agree collectively to keep that obligation, I think the members in the
> future will keep that obligation.
>

Rogers Cadenhead wrote:
> Whether individual board members retract their statements seems less
> relevant to me than the language of the proposal, if it passes. If we
> agree collectively to keep that obligation, I think the members in the
> future will keep that obligation.

I think that's a little naive. I'd hate to think that the board couldn't
vote to correct past mistakes, even if that means allowing the board to undo
good decisions.

What scares me is that something that should be unthinkable, clearly isn't.

Regards
James

On Nov 28, 2009, at 2:31 PM, Rogers Cadenhead wrote:

> If the proposal passes, Yahoo is going to forward its old URLs to the
> documents on the RSS board web site.

For me, it was simply a question of what's going to happen with the old URLs.

The aforementioned statement answers my question.

On Sat, Nov 28, 2009 at 6:08 PM, James Holderness <j4_james@...> wrote:
> What scares me is that something that should be unthinkable, clearly isn't.

The confusion occurs because namespace URIs look like web addresses,
so people naturally think that when the web address changes the URI
should change as well.

Neither solution is perfect. If the owner of the domain that matches
the URI stops forwarding, it will confuse some people who go looking
for the namespace documentation at that URI. But one of the things we
can do as a board is to help people realize that a namespace URI is
just a unique identifier. It doesn't have to be associated with a web
page.

As to whether it's naive or not, as a board we've been extremely
conservative about making changes to things that affect existing
implementations. That's why we published the RSS Profile instead of
revising the specification to address things like the multiple
enclosures issue. My expectation is that we'll continue to tread
carefully.

We have an opportunity here to help the Media-RSS community. The
proposal that Ryan and I drafted is the result of more than a year's
communication with Yahoo and Media-RSS developers to achieve the
strongest consensus going forward. It would be a shame not to take
this opportunity because of what I regard as a minor concern -- the
idea we'd change the namespace URI after explicitly promising not to
do so.

Rogers Cadenhead wrote:
> It would be a shame not to take
> this opportunity because of what I regard as a minor concern -- the
> idea we'd change the namespace URI after explicitly promising not to
> do so.

I agree. But I don't think it's asking a lot to expect some clarification
from board members about whether they really would stick to that promise.

Given what has been said in this thread, it seems to me that some people
either don't realise that they're making that promise by agreeing to the
proposal, or that they think it's just a temporary commitment that they can
back out of if circumstances change.

Regards
James

On Sun, Nov 29, 2009 at 2:25 PM, James Holderness <j4_james@...> wrote:
> Given what has been said in this thread, it seems to me that some people
> either don't realise that they're making that promise by agreeing to the
> proposal, or that they think it's just a temporary commitment that they can
> back out of if circumstances change.

I think it's good that you've called attention to this aspect of the
proposal. It will help ensure that board members know the significance
of that provision.

The vote begins tomorrow, so I hope that members who have concerns or
comments will post today.