What happens when the authors of the FeedValidator can’t decipher a specification?
All specs have ambiguities, and authors of validators tend to
worry about details that others don’t. For example,
what happens if a single rss item contains two different
<itunes:explicit> elements? The
spec doesn’t say, but it clearly isn’t something
that most people would expect to encounter, so I have no problem
marking it as an error. I’m also prepared to back off
if somebody were to challenge this with anything remotely
approaching a plausible rationale.
Nor am I overly worried about whether or not values for
<itunes:explicit> are meant to be case
sensitive, or how to deal with abbreviated durations. Despite
the fact that the spec says that durations are to be formatted as
HH:MM:SS, I’m confident that the example of
7:04 is meant to be equivalent to
07:04:00 or even
No, I am talking about
cases where there is no description at all of the
permissible values for
<itunes:block>, nor are
there any samples provided to base a guess on. And cases like
<itunes:image> for which the provided sample
looks nothing like the specification.
Yahoo! initiated the development of Media RSS 1.0 on an open mailing list. Whether you like or hate the spec, it unquestionably was developed in the open, in a manner that enabled anybody who cared to participate to do so. And, if you have any questions or comments, you certainly know where to find the authors.
Later, Microsoft initiated the development of the
Simple List Extensions. Apparently, it was worked on
in private over a course of months, and while a select few industry
experts got an
early peek opportunity to
with Microsoft on enhancements to RSS 2.0 privately without others in
the loop, while the rest of us only got to see it after it was
unveiled with great fanfare at what has become a
very professionally run
After it became clear that this process produced a suboptimal extension, Microsoft has indicated so far that they will make one concession, and created a weblog (with comments enabled!) and a wiki for feedback. Both of which seem to have been promptly ignored, with the notable exception that some of us have have gotten emails from a person identifying himself as a “senior project manager on ie”. No thanks, but for now, I’ll pass.
All this from a company that clearly understands weblogs. Where “clearly understands” in this context means “steps out of the way, and lets their employees do what they feel is right”.
Finally, we have a company with a legendary reputation for secrecy (Apple) creating PodCasting specifications. Whose webpage responds with “itmss is not a registered protocol” when you click on “learn more”. Gob-smackingly ignorant indeed.
Admittedly, this is just three data points, but I really don’t like the trend I’m seeing.
Raising the flag
So, returning to the question posed at the top of this post, “What happens when the authors of the FeedValidator can’t decipher a specification?”
I’m really tempted to have the FeedValidator return an
“Undecipherable Specification Error” if it ever
Perhaps that will get noticed.
Eventually.Update: I stand corrected.