[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Postel's Law Has No Exceptions

• To: <xml-dev@l...>
• Subject: RE: Postel's Law Has No Exceptions
• From: "Danny Ayers" <danny666@v...>
• Date: Thu, 21 Aug 2003 00:29:47 +0200
• Importance: Normal
• In-reply-to: <JIEGINCHMLABHJBIGKBCAELKIDAA.julian.reschke@g...>
• Reply-to: <danny666@v...>

I doubt whether any law of constraint aside from Aleister Crowley's can
really be said to apply in the web environment. But I see sense in putting
MUSTs in specs. Otherwise the sheep will just wander off. In the case of
syndication feeds, I think a little yapping dog like a warning light in
consumer tools to shame any dodgy feed producer would probably be a very
good idea.

Cheers,
Danny.

> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@g...]
> Sent: 20 August 2003 20:22
> To: Joshua Allen; Julian Reschke; Simon St.Laurent;
> xml-dev@l...
> Subject: RE:  Postel's Law Has No Exceptions
>
>
> > From: Joshua Allen [mailto:joshuaa@m...]
> > Sent: Wednesday, August 20, 2003 7:46 PM
> > To: Julian Reschke; Simon St.Laurent; xml-dev@l...
> > Subject: RE:  Postel's Law Has No Exceptions
> >
> >
> > > My point being, unless *everybody* is accepting the same kind of
> > broken
> > > requests, interoperability will actually be *worse*. But if indeed
> > > everybody *is* accepting the same requests, it would have made more
> > sense
> >
> > 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.
>
> Julian
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
>

• References:
  • RE: Postel's Law Has No Exceptions
    • From: "Julian Reschke" <julian.reschke@g...>

• Prev by Date: RE: opposite of infoset
• Next by Date: RE: opposite of infoset
• Previous by thread: RE: Postel's Law Has No Exceptions
• Next by thread: RE: A standard approach to glueing together reusable XML fragments in prose?
• Index(es):
  • Date
  • Thread