Re: Will Atom have a "don't process invalid documents" rule?

["Bill Kearney" <wkearney99@xxxxxxxxxxx>]

> 1. Even if we have this rule, there will be invalid feeds. Someone will
> write some code, they'll test it, it'll work, and then one day they'll
> have a weblog entry that includes AT&T or ]]> or something and their
> feed will break and they won't notice.

So shame the developers into fixing their code instead of coddling their
laziness.

 Better to /see/ that the errors exist instead of having hidden error handling.
Besides, if it's open source then it's very likely a fix can be made without a
tremendous amount of effort.

> 2. Aggregators compete for users. Users want to read these feeds, even
> if they're broken. Users will switch to aggregators that read these
> feeds and the rule will be useless, since folks will likely test with
> those aggregators. The only way we can keep the rule in effect is by
> getting _everyone_ who writes an aggregator to act against the wishes
> of their users, which seems like a bad idea.

Being as I've had extensive contact with feed and content producers I can say
this is bunk.  It's been my experience that if a feed is found lacking the
providers have all been grateful to be notified of the error and have speedily
rectified it.  There's no sense in allowing for coddling bad data when
*experience* shows the producers aren't unwilling to fix problems if and when
they arise.

> 3. Essentially the same effect can be achieved by having a validation
> display (like Straw's smiley face) and an easy-to-use validator.

I disagree.  While an easy to use validator is certainly key, if a popular
aggregator doesn't throw up on the error then it's doing more harm than good.
Let's not fall prey to the notion that half-assed, but popular tools, should be
allowed to needlessly complicate things for others.

> 4. This is not to say that all aggregators should have to process
> invalid documents, or that they should work have to guess about what
> the feed author meant, or that we should encourage or tolerate bad
> feeds. We should try still try to get rid of bad feeds, but taking
> things out on the users is the wrong way to do it.

If it's made clear from the outset, the spec is reasonably robust and the
initial validator is rigorous in checking and informative on finding errors it's
entirely likely bad feeds won't happen.  That's not to say they can't happen but
when the examples are clear enough and the validator is tough enough, those
experimenting with the format can take it upon themselves to make things
correctly, right from the start.  Conversely when the examples are weak,
inconsistent or overly complex (bordering on bizarre) and there's no validator
(or a weak one) then initial development efforts will make a half-assed attempt,
publish code and drag their feet on fixes (while everyone gets into feature
creep pissing matches).

The analogy I use is a ride at the amusement park.  The sign says 'you must be
this tall to ride'.  It's up to them to do what it takes to meet the criteria.
If it's made clear enough and reference implementations are robust enough, then
setting the bar 'that high' won't be a problem.

-Bill Kearney