intertwingly

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 00:07:04, not 07:04:00 or even 70:40:00.

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.

Conversations

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 work 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 conference.

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 encounters an <itunes:block>, <itunes:image> or <itunes:link> element.

Perhaps that will get noticed.

Eventually.