I honestly thought that skipDays was going to be an easy place to start,
and then I would move onto skipHours, see if this group really was
serious and then decide whether or not I should continue with this effort.

The Netscape 0.91 specification simply noted that the day sub-element
was element was required. The current draft says "This element contains
up to seven day elements identifying the days to skip." I fully expected
this to quickly be replaced with text that says that the day element was
required and that duplicates are not allowed. Doing so would not add
appreciable verbiage to the spec, in fact by saying "no dupes", you no
longer need to say "up to 7". I also can't imagine this affecting any
existing feeds, particularly as this element is virtually never
produced, and is respected even less. I certainly didn't expect private
hate mail as a result.

The issue with skipHours is a bit more problematic. It does not exist
in RSS 0.90, RSS 1.0, or RSS 1.1. It does exist in RSS 0.91, 0.92, and
2.0. In 0.92, it ranged from 1 to 24. In one version of 0.91 it ranges
from 0 to 23, in the other it ranged from 1 to 24. In some versions of
specifications that call themselves 2.0, it ranged from 0 to 23, and in
others 1 to 24. And then there is the statement that all 0.92 feeds are
valid 2.0 feeds to consider.

You can't reliably use the presence of DTDs, doc elements, or the
spelling of textInput (vs textinput) to determine which version you are
dealing with, as these are are all optional in RSS 2.0. And with
multiple conflicting versions calling themselves 0.91 or 2.0, you can't
use the version attribute either.

The Feed Validator's position on this is simple: it ducks. Ever since
November 11, 2002, it has not declared feeds which specify a '0' as hour
as invalid. Nor does it declare feeds which specify a '24' as invalid.

My recommendation is that the new draft take a similar approach. Drop
the "up to 24 elements" language. Specify that hour is required, ranges
from 0-24 (with both 0 and 24 representing midnight), and that
duplicates are not permitted. Simple. Clear. And backwards compatible.

How issues like these are resolved can make the difference between
whether the Feed Validator treats this draft as yet another
specification that calls itself RSS 2.0, or as the authoritative
version. And whether or not it is productive use of my time to continue
to attempt to correlate Feed Validator test cases with the proposed RSS
2.0 draft.

- Sam Ruby