Validator 0.8 getting stable - what next?

I didn't get to announce properly the releases of the Markup Validator 0.8.0 and 0.8.1 here, so these will be bulked with today's special: the Validator version 0.8.2 is out.

0.8.0 was a big step forward, bringing reliable XML support at last, and a faster parsing engine. Since then, the work has focused a lot on tons of little bug fixes, and usability. The latest release is no exception, and as the release announcement summarizes, 0.8.2 was mostly about making it easier...

The pleasant thing about releasing (relatively) often is that we get to look at the roadmap, with a critical eye, regularly. A few months ago, when the development roadmap was last revamped, it was obvious in my mind that the next big effort would be localization. Am I still absolutely certain that localization should have a high priority? Sure. As a tool that wants to help Web developers everywhere, being available in English only is a liability for the Markup Validator. But other work items are vying for attention too.

One of the most pressing of those is the question of "what we validate against". Up to the mid-noughties, most languages standardized at W3C were formalized with SGML and XML DTD grammars. The Validator was (and still is) using a fantastic engine for parsing documents against DTDs: opensp.

In the past few years, however, new schema languages came and were able to express much more than DTDs did. Namespace support (something unfortunately alien to DTDs) and extensibility, notably, made people look for other solutions. With a number of languages (e.g. SVG 1.2) based on such schema languages as RelaxNG or XML Schema getting mature, and other languages considering not having any kind of formal grammar at all, it is time for the validator to add new tricks to its bag - while keeping strong and reliable support for validation of older document types, which still make most of the web. It is a great time for experimentation: there will be much to learn, and adopt, from other projects such as relaxed or html5lib. Maybe some of this will be spun to other projects, tied together via the Unicorn framework. Experimental work should also be a good time for developers to join the project: it's always more fun to experiment and build new things than focus on fixing bugs in ten-years-old code.

Ultimately, where the validator goes will also be influenced greatly by its users. For example, after a relatively quiet start, the Validator's API is getting more and more attention, and some developers are joining the validator's mailing-list with tons of ideas. Good, constructive ideas and working patches are generally the best way to influence an open source project, so expect some interesting evolution in this area...