W3C home > Mailing lists > Public > www-tag@w3.org > November 2003

saved wording re liberal/conservative.

From: Tim Berners-Lee <timbl@w3.org>
Date: Tue, 18 Nov 2003 16:45:25 +0900
Message-Id: <2C245835-199B-11D8-8003-000A9580D8C0@w3.org>
Cc: www-tag@w3.org
To: Ian Jacobs <ij@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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:02 UTC