Re: Will Atom have a "don't process invalid documents" rule?

["Bill Kearney" <wkearney99@xxxxxxxxxxx>]

I certainly favor "must reject".

As the saying goes, "People in Hell want ice water".  Asking for processing of
semi-valid pseudo-XML is like them asking for a damned lemon twist in it.  The
burdens this puts upon the various tools expecting to consume the data is
non-trivial. (error handling code is notorious for introducing more bugs)  Not
to mention, the first jackass vendor that starts screwing around with the format
claiming the spec is too funky or something, while making invalid data, is going
to needlessly distract the effort from making useful progress.  It's not like
/that/ hasn't been seen before...

Better to say it MUST be valid at the outset.  If they can't make it work then
let the validators, marketplace and competing products shame them into
compliance.

-Bill Kearney

----- Original Message -----
From: "Simon Willison" <cs1spw@xxxxxxxxxx>
To: <atom-syntax@xxxxxxx>
Sent: Monday, August 18, 2003 7:05 PM
Subject: Will Atom have a "don't process invalid documents" rule?


>
> Tim just mentioned a mandatory order for the <issued>, <modified> and
> <created> elements, hence my question. Will the final Atom specification
> include text along the lines of "client implementations MUST reject Atom
> feeds if they are invalid". The benefits of this are obvious: if clients
> follow the spec, anyone implementing their own Atom feed will instantly
> realise if they have made a mistake when they go to test it. The instant
> disadvantage is that Aggregators are tools for users: if a feed is
> invalid, user's would rather it "just worked" than it threw an error
> message.
>
> It's an age old debate I know, but has it been discussed with respect to
> Atom?