On Fri, 5 Nov 2004 00:18:13 -0800, Roy T. Fielding <[EMAIL PROTECTED]> wrote:
For example, a > headline > that says "Received feed contained errors due to SOFTWARE THAT SUCKS > or temporary communication errors." Guess how long it will take for > the real maintainer of that feed, not the poor dudes trying to support > the HTTP server, to fix the problem? A popular view is that end users don't care about data errors, they simply want the information. 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? > 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. > 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. > Should we encourage Atom 0.3 clients to send an error message whenever > they receive a Atom 1.0 feed? How about when 1.0 clients receive a 1.1 > feed? What on earth makes people think that client software is capable > of differentiating between broken feeds and features that are simply > unknown to that client? Separate issue. We do need to sort out versioning so that a client can tell the difference between a broken feed and a different version. > Second, the people who read error logs are not the people who care > why the feed is broken. Depends on the nature of those logs. If the information appears in a prominent place in the content management system, the right people will see it. > Third, it is a waste of bits. Quite the opposite. If the error isn't reported, then the publisher will continue to serve bad data to the million clients indefinitely. Even if it takes a billion reports before something is done, thats still bless wasteful than open-ended junk distribution. > 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? Cheers, Danny. -- http://dannyayers.com
