Re: well-formedness error

[Danny Ayers <danny666@xxxxxxxxxxx>]

James Robertson wrote:

> 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".


Perhaps, but the rules themselves shouldn't be lenient.


> > 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.


There's nothing to support that statement. We aren't writing RSS 2.1 but 
a whole new spec, and I believe that the error rate can be significantly 
lower. Can't help but be in fact, given the variation in the RSS specs.

> 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?  


Yes. In the interests of reducing that percentage.

> 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.


But we aren't talking about patching existing systems, we're talking 
about new systems based on a new spec.

> 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....


Ok, for simple newsreaders it may not involve much work. But Atom can 
and should support a larger range of applications than browser replacements.

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


That is a problem for any new development.

Cheers,
Danny.

--

Raw
http://dannyayers.com