Log Validator 1.2: new features we didn't know we wanted.

The W3C's Log Validator was first developed as an internal tool to help W3C manage the cleaning up of markup in the hundreds of thousands of hand-coded HTML documents scattered across the w3.org Web space.

As most internal tools, its feature set was closely dictated by the peculiar structure and needs of its first customer. To the question "how do we batch-validate all our pages?", the W3C's answer was "Maybe we want to get the results little by little, and fix a few pages a week. At least we should make sure that the pages that are accessed a lot are clean and interoperable." A tool was born, and a no-nonsense process formulated. The next question was "Can we make sure that there invalid documents are not created faster than we are fixing them?", and the log validator was modified to work as a batch validator for any list of links, and hooked to the commit history of W3C's publishing system.

Most tools will only evolve if it invites new customers, and their needs. Even when the features that come as a result can seem a little strange. Does anyone want to process their server logs and find the 100 most popular valid HTML documents? I would have no use for this, and it may sound rather useless. But when a manager of the department of commerce of a large government came and asked whether our tools could be used (among other criteria) to assess the quality of Web sites for a contest, we had to come up with a way for the tool to not just report about invalid entries, but also valid ones, and the ones that the validator(s) gave up on. As a result, the logvalidator became more flexible in its output.

Does it sound like a silly feature to add for a single "customer"? It is not: the new customer brought tons of interesting real-life test cases, and we fixed half a dozen bugs already, thanks to them. Sometimes an odd feature request goes a long way.