Valid
The client is the wrong place to enforce data integrity. It’s just the wrong place. I hear otherwise intelligent people claim that “if everyone did it, it would be okay.” No, if everyone did it, it would be even worse. If you want to do it, of course I can’t stop you. But think about who it will hurt.
6 Comments RSS · Twitter
Omigosh this blog is awash in common sense too! ;)
The problem with lax acceptance is that it encourages people to write to one client, rather than sticking with the standards. History has shown where Pilgrim is wrong; all he needs to do is scan his referrer logs.
If ClientX reads and presents bad data in a specific way and a majority of publishers use ClientX to "validate" their data, then ClientX gets a lock-in and competing clients have to emulate ClientX's idiosyncratic behavior, and it's unlikely they'll match it completely.
Requiring a client to complain about bad data is the only way to insure that specifications remain worthwhile and no single vendor seizes control of the data domain.
I think there's got to be some middle ground where the client isn't completely strict (refusing to display anything that isn't valid) yet it also displays some sort of error (like iCab's frown) when it detects that the document isn't up to spec. That way the user knows there's an error and can perhaps contact the maintainer of the feed, but the software still tries to do right by the user in case the feed doesn't get fixed.
Here's more from Brent Simmons. I think he's being sensible about this.
If the programs consuming the data can't require valid data, then what is the point of having a spec in the first place?