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

Re: Heed this warning about Postel's Prescription

• From: "Liam R. E. Quin" <liam@w3.org>
• To: "Costello, Roger L." <costello@mitre.org>
• Date: Sun, 28 Jun 2015 23:00:32 -0400

On Sun, 2015-06-28 at 19:59 +0000, Costello, Roger L. wrote:
> How might Postel's Law be applied to web services that receive XML 
> and sends out XML?

Postel was writing about the protocol layer, not the application layer.

Robust software should not crash when given invalid input but that 
does not mean it has to recover from syntax errors. Rather, when 
necessary, it should detect errors and report them.

The receiving application should have flexibility where practical to 
do so in the face of options. The world in which the aphorism 
originated was one in which two IBM mainframes might not be able to 
share text files because their variants of EBCDIC differed, or where 
two printers made by the same company on an early network couldn't be 
driven by the same driver because one implemented and required option A
and not option B, and the other did it the other way round. (This 
situation also gave rise to PostScript, heavily influenced by Xerox 
Interpress but with every implementation having all core features).

Every optional feature in a spec has the potential of doubling the 
implementation complexity, the cost of testing, and of halving 
interopreability.

You have to weigh this against the cost of errors.

For a network protocol it's likely there's a higher-level checksum, so 
that errors will be detected. For XML, often we're describing metadata 
or document-level information, and tests can't easily be automated. 
For example, you can maybe test that every author element refers to a 
person listed in the Library of Congress database (far from perfect 
itself of course, like most large data sets) but then if you get the 
author and title of a biography switched you're hosed. So there's some 
value in the redundancy. SGML veterans will remember the cost of 
supporting projects making heavy use of minimization features with 
errors in the markup, and when we made XML from SGML one of the first 
things to be evicted was minimization.

It's interesting that we don't often hear requests for error-
correcting JSON parsers. The spec has become if anything stricter over 
time.

Liam


> 
> Here are two ways:
> 
> 1. The web service is willing to receive UTF-8 XML documents 
> containing a pseudo-BOM. The web service sends out UTF-8 XML 
> documents without a pseudo-BOM. [1]
> 
> 2. The web service is willing to receive XML character streams with 
> Unicode decoding errors: it processes the character stream by 
> replacing the offending bytes by the Unicode replacement character 
> U+FFFD until it manages to resynchronize the UTF-{8,16} byte stream. 
> The web service sends out XML documents without character decoding 
> errors. [2]
> 
> /Roger
> 
> [1] See Rick Jelliffe's post on the xml-dev list: 
> http://lists.xml.org/archives/xml-dev/201506/msg00065.html
> 
> [2] See Daniel Bunzli's post on the unicode list: 
> http://www.unicode.org/mail-arch/unicode-ml/y2015-m06/0247.html

• References:
  • Heed this warning about Postel's Prescription
    • From: "Costello, Roger L." <costello@mitre.org>
  • Re: Heed this warning about Postel's Prescription
    • From: Rick Jelliffe <rjelliffe@allette.com.au>
  • RE: Heed this warning about Postel's Prescription
    • From: "Costello, Roger L." <costello@mitre.org>