Lists Home |
Date Index |
> From: Joshua Allen [mailto:firstname.lastname@example.org]
> Sent: Wednesday, August 20, 2003 7:46 PM
> To: Julian Reschke; Simon St.Laurent; email@example.com
> Subject: RE: [xml-dev] Postel's Law Has No Exceptions
> > My point being, unless *everybody* is accepting the same kind of
> > requests, interoperability will actually be *worse*. But if indeed
> > everybody *is* accepting the same requests, it would have made more
> Well, I understand the point that Tim makes WRT HTML -- you're not doing
> the client any favors by accepting his buggy input, since it's bound to
> cause him grief later on. The computing equivalent of "a *real* friend
> would have told me about the kool-aid stains on my shirt!"
> But it seems you are making a different point. I am saying that WebDAV
> interop issues were not caused by any noble attempts to be "liberal",
> but rather by broken code. You seem to be responding that "yes, it was
> buggy for the big guy, but then everyone else had to follow suit and be
> liberal to achieve interop". I can understand this much, but what is
> the conclusion we should draw from this? What is the relevance to the
> debate about draconian XML processing rules?
None. All I wanted to say is that draconian error checking is very good, and
that it should be used as frequently as possible.
Just recently we had a very weird discussion on the WebDAV mailing list
about a MUST-level requirement for servers where it was suggested that
clients SHOULD handle the case gracefully where the server breaks that
requirement . That's exactly how not to apply Postel's law.
> Are you suggesting that the smaller vendors would have been *better* to
> be draconian? At first glance, this seems like an issue of "the big guy
> creates defacto standards" rather than something directly related to
> Postel's law. What am I missing?
Possibly nothing. My impression is that The Robustness Principle is
frequently used as excuse to defend broken implementations. The robustness
principle is *not* about accepting requests that are clearly
malformed/broken/incomplete/whatever -- it is about expecting malformed
requests to come in and behave sanely in that case.
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760