On Atom and Postel’s Law

Volume 7, Issue 5; 12 Jan 2004; last modified 08 Oct 2010

While it’s true that a number of the political factors that influenced the draconian, anti-Postel’s Law design of XML have gone away, I still think that design is virtuous and correct.

Give them an inch, and they’ll take a yard.

I learn by way of Ongoing that some folks in the Atom community want to support not only feed content that’s not well formed (read “broken”) but whole feeds that are not well formed (read, well, since I don’t want to offend you, dear reader, I’ll let you imagine imprecations of your own; preferably the sort that would make an ex-con blush).

A number of rants on this subject drifted through my head as I went through the Monday morning chore of getting the garbage and recycling out to the curb. But in the end, I realized that this is a natural and obvious progression from the position that feed content need not be well formed.

Look, if you’re building a specialty parser to deal with random goop anyway, I can see that there’s little reward in being strict about any part of the format you’re parsing.

While it’s true that a number of the political factors that influenced the draconian, anti-Postel’s Law design of XML have gone away, I still think that design is virtuous and correct. XML succeeded in part because it is an exception to Postel’s Law by axiom. I believe this property remains an important part of its continued success.

For crying out loud! If you don’t want Atom to be XML, make it something else: RFC 822 name/value pairs, comma separated values, free text, whatever. But please, do the world a favor, take out all the angle brackets and things that look like XML. There can be no virtue in a design that intentionally misleads the user.


I strongly agree.

—Posted by Tobi on 13 Jan 2004 @ 01:03 UTC #

There are two interpretations of Postel's Law: the conservative and the liberal. The conservative interpretation is that if there is an ambiguity in a specification then you should:

1. Be careful not to produce data whose compliance is ambiguous.

2. Be careful to accept any data which might reasonably be considered to comply with the specification.

Also, maybe you should fix the specification.

The liberal interpretation of Postel's Law is that even data streams which unambiguously do not comply with the specification should be accepted.

I'm fully in favour of the conservative interpretation but I think anybody who supports the liberal interpretation rather misses the point of having a specification in the first place.

—Posted by Ed Davies on 13 Jan 2004 @ 01:34 UTC #

Good point, Ed!

—Posted by Norman Walsh on 14 Jan 2004 @ 03:51 UTC #

This page is not valid XHTML ( http://validator.w3.org/check?uri=http://norman.walsh.name/2004/01/12/postel ). Luckily for you, my browser is very forgiving, and displayed your little rant as best it could. And thank goodness for that, otherwise we would not be able to have this stimulating conversation!

—Posted by Mark Pilgrim on 14 Jan 2004 @ 06:08 UTC #

It is probably worth noting at this point that Tim Bray just called you a bozo and an incompetent fool. http://www.tbray.org/ongoing/When/200x/2004/01/11/PostelPilgrim

—Posted by Mark Pilgrim on 14 Jan 2004 @ 06:18 UTC #

I've a feeling that XML isn't actually an *exception* to Postel's law, because XML isn't designed to be robust at this level. The 'law' simply doesn't apply. Try applying Postel to RDBMS clients.

—Posted by Danny Ayers on 14 Jan 2004 @ 03:58 UTC #

I think Postel's Law needs an addendenum: be liberal in what you accept *unless you have reason to believe the other side (be conservative in what you send) will not hold up their end of the bargain*.

It's abundantly clear from HTML's history that unless there is pressure to author well-formed markup, then a vast number of people simply won't make any attempt to "be conservative in what they send". Without this attempt, Postel's Law falls to pieces and developers get caught in an error-handling arms race.

Mark, I've noticed you are in the habit of pointing out when an XHTML page is invalid. You are supporting my point by doing so - when served as text/html, there is *no pressure* to send well-formed XHTML, and people simply don't put any effort into doing so. If you were pointing out malformed XHTML when it will actually be treated as XML you would be supporting your point.

Also, pointing out that an XHTML document is invalid is of no consequence - you should be pointing out when an XHTML document is malformed, since the issue is whether XML documents are well-formed or not, not whether they are valid or not.

—Posted by Jim Dabell on 16 Mar 2004 @ 01:49 UTC #