- From: Henrik Dvergsdal <henrik.dvergsdal@hibo.no>
- Date: Tue, 17 Apr 2007 09:27:34 +0200
- To: public-html@w3.org
On 16. apr. 2007, at 23.32, Ian Hickson wrote: > On Mon, 16 Apr 2007, Henrik Dvergsdal wrote: >>> >>> Putting forward a formal schema causes people to claim that things >>> that are not caught by the schema are allowed, even when this >>> contradicts other claims in the specification. >> >> I don't see this as a major problem. Most competent developers >> will be >> aware that this is only a partial check, especially if we warn about >> this in text and descriptions. > > It is a huge problem, IMHO, because most developers aren't > competent by > that definition. First of all: I'm sorry for introducing the term "competence" into this discussion. As I indicated earlier: There will always be aspects of programming languages (and programs) that aren't automatically checked. This is just a question of where to draw the line. Everyone knows that running a HTML document successfully through a syntax checker is no guarantee that your document or program is correct. This comes from experience - we are quite used to getting things wrong from time to time, even when our documents validate. > Also, I _want_ my tools to catch as many errors as > possible. Having the spec artificially limit what errors can be caught > seems like an unnecessary limitation. I cannot see how having an official schema (or an official set of schemas) imposes any limits on our tools. > (And if we do have a spec schema, > and it doesn't catch everything, you know people will claim that > conformance checkers that catch mistakes the spec schema wouldn't > flag are > buggy and are reporting bogus errors. I don't think so. If they wonder about errors from a conformance checker, they will consult the spec and not the schema, especially if the errors are accompanied by text encouraging them to do so. -- Henrik
Received on Tuesday, 17 April 2007 07:28:03 UTC