- From: Tim Berners-Lee <timbl@w3.org>
- Date: Tue, 18 Nov 2003 16:45:25 +0900
- To: Ian Jacobs <ij@w3.org>
- Cc: www-tag@w3.org
We discussed though didn't put in the document the saying, "Be liberal in what you accept and conservervative in what you do." I mail it just to save it in some archive. There are 3 situations which raise the questions 1. because the spec is not clear or one worries that it won't be clear to others. In this case, to be liberal is dangerous, as it prolongs the situation in which the spec is unclear. This in turn may lead other implementers to make incocnsistent interpretations of the space and make non-interoperable and error-prone systems. Example: the spec says "The language is a sequunce of lines", and the engineer is tempted to just accept a complicated pattern on LF, CR, NUL and NL characters just to be safe. It is better to go fix the spec. 2. because the spec says to. This is a problem with the specification. It officially puts implementers to the trouble of the extra work of being conservative and liberal appropraietly, but in fact may lead people to rely on such behaviour and reinterpret the spec asn being lenient in an incompatible way. Example: The spec says that parsers are to accept a complicated pattern on LF, CR, NUL and NL characters as line endings, but generators to only generate single LF characters. In practice, a series of generators generate files with line ends being CR characters, and they work, until similarly a parser implementer assumes that it can accept single line feeds. The problem is never noticed until the bad parser happens to be connected to the bad generator. 3. because it is actually more efficient to be more liberal. There may be cases in which it is much easier or faster to make a paser which accepts a more liberal langauge than the spec. In this case, it is a waste to insit that a conforming parser completely verify that the incoming document is syntacically valid, when speed is of the essense and it is reasonable to assume that the incoming data is syntactically correct. Example: Suppose the XML 1.1c specification were to determine that all XML documents must be in Unicode canonicalized in a given form. The actual checking of this cannonicalization is process or time intensive. The parser is written to be more liberal than the specification. The system works because all the generators are well tested to always generate canonical XML. In this case, for the spec to say that the parser was not conformant would be a mistake.
Received on Tuesday, 18 November 2003 02:48:50 UTC