On Nov 5, 2004, at 3:04 AM, Danny Ayers wrote:
A popular view is that end users don't care about data errors, they simply want the information.
That would obviously depend on the nature of the error and how it impacts the information. I don't know of anyone who thinks silent acceptance of errors is a good thing. I did not suggest something stupid like a pop-up box that interrupts the user and asks that they confirm that the server's software sucks -- there are many ways to indicate an error such that it won't even be noticed by those users who don't care.
<http://www.w3.org/TR/webarch/#error-handling>
An impact of this has been the development of 'liberal' parsers. Yes, quite a few people on this list saw some benefit in flagging errors to the end user, but I'm sure we will see plenty of clients that silently ignore errors. But even if errors are flagged, what is the end-user expected to do, especially when they can still read the feed data thanks to cleaning heuristics?
The first end-user is almost always the author of the feed in question, particularly when new software is deployed.
Another method of doing the same thing is to simply test the bad software and post a "hall of shame" web page that explains the errors.
Sure. But these kind of techniques are already available for RSS (e.g. Syndic8). Yet there are still plenty of applications that (usually intermittently) deliver ill-formed data.
Because there are other techniques doesn't mean the technique being proposed isn't desirable.
No, it just means it isn't needed. The technique is undesirable for other reasons.
Sending feedback to the HTTP server is a bad idea. First, feed errors are more likely to be caused by bad client software that mishandles its own reads.
Do we have evidence of that in the context of syndication? I suspect that the vast majority of errors are above the HTTP level. Most clients ignore the XML mime RFC, but assuming they've guessed a workable encoding they can tell if the XML is ill-formed or not.
No, we don't have "evidence" of that in syndication -- we only have experience that can be drawn upon from 11 years of deploying services on top of HTTP. Generally speaking, sending an HTTP server an error message means it will be read either by no one or by the HTTP server maintainer, not the application maintainer. I know that for a fact because I wrote one of the first log analyzers (wwwstat) and have dealt with Apache httpd users since day one, and not once have I ever encountered an application developer that quoted from the error_log (even when the documentation specifically says to look there first).
Finally, if feeds are supplied in a reasonably efficient architecture that can take advantage of hierarchy and proxies, then the actual source of feed errors may have no relation to the feed source.
If they are supplied in a reasonably functional architecture, then the errors won't be occurring en route. Again, do with have evidence that this is the likely case in syndication?
Proxies are hard to do right. I am not aware of any HTTP proxies in current use that do not introduce errors to the stream under some circumstances, in spite of the specifications being stable for six years now.
Cheers,
Roy T. Fielding <http://roy.gbiv.com/> Chief Scientist, Day Software <http://www.day.com/>
