Re: well-formedness error

[James Robertson <jarober@xxxxxxxxxxxxxxx>]

At 06:43 PM 6/16/2004, you wrote:
> James Robertson wrote:
>
> > Yes, and the simple problem is that on a hosted site it's easy for the 
> > headers to not match what the feed has.
>
>
> So we need to figure out strategies to minimise the occurrence of this. 
> For the most part, the software that is generating the feed should look 
> after it, either programmatically or by adding corrective .htaccess files.

Yeah, that'll work.  While you're at it, fix all the bad html out there too :)

I'm cynical about this, and don't really expect it to get better.  Which 
means that aggregators have to be prepared for anything, and be lenient 
over the "rules".



> > This is one of the (many) reasons that aggregator developers have to be 
> > lenient with malformed content.
>
>
> Aggregator developers don't have to be lenient, it's a choice. My own 
> choice to date has leaned towards being lenient with RSS feeds (although I 
> can't honestly remember the last time I encountered the wrong-mime-type 
> problem), but I would prefer to be strict with Atom feeds. As an 
> aggregator user I would prefer to use a tool with useful features rather 
> than one that sacrificed them for cleaning up bad feeds.

Yeah, it's a choice :) We can be lenient and have users, or be strict and 
not have any.  I suppose the latter course would be easier on me as a 
developer, but then again - as a user of my own software, I also want to 
read content that might not strictly conform to all the specs.  As to your 
last sentence - if that meant not reading the percentage of feeds that Dare 
brought up earlier, would you still go that way?  Blithe assertions that 
these things "are easy to fix" on the server mean little   - there are 
patches out there for most of the known security issues in Windows (and 
Linux, etc.), and that's a MUCH more critical problem, with actual money in 
play.  And yet, tons of systems don't get patched in a timely fashion.

My basic theory is, if people don't patch their systems against known 
issues (and I'm not just talking clients here - plenty of servers are 
unpatched as well) - then the liklihood of feeds with the problems Dare 
brought up being fixed is about nil.


And obtw - there is no tension between "accepting bad feeds" and adding 
features.  In BottomFeeder, I did all the work to deal with the most common 
classes of problems months ago - I haven't so much as looked at that code 
since then.  And even when I was working in it, it was a simple matter of

-- subclassing the XML Parser
-- overriding a handful of messages that raised errors and instead having 
them just log those errors

That's pretty much it; there was no choice between "extra work to handle 
errors" and "adding features".  If it's extra work, I would suggest that 
perhaps the platform and tools selected were a problem....


Sure, the fixes are easy.  But you are pushing uphill against the strongest 
force known to man - inertia :)

> Cheers,
> Danny.
>
> --
>
> Raw
> http://dannyayers.com

<Talk Small and Carry a Big Class Library>
James Robertson, Product Manager, Cincom Smalltalk
http://www.cincomsmalltalk.com/blog/blogView
jarober@xxxxxxxxxxxxxxx