Recently, we're trying something new. :-) We're going to start splitting development into "releases"; that is milestones with a version number. We've done a few already, arbitrarily named 0.5.0 and 0.5.1, that mainly existed as CVS tags to make bug fixing easier. Right now I'm trying to stretch this concept a little further by planning features for future versions in advance.

As a result, you will find several lists on this page now; one for each planned version and one for general "some time when I get a round tuit" stuff. As releases are made, the TODO items for that release may get moved to a separate "Changelog/Release Notes" page, but if lazyness wins out they may just stay here after all. :-)

Validator v0.6.0

Fix up all absolute URIs to be relative (to aid local installations). Thanks to Alex Holst for the reminder. Thanks to Ville Skyttä for the patch.
Fix up Validators temp file handling to use secure temporary files. Thanks to Alex Holst for the prod... :-)
Fix up Validator to be "-T" clean. Thanks (again) to Alex Holst for the prod... :-)
Make it run under mod_perl.
Apply Ville Skyttä's patches.
Move entirely to OpenSP instead of a custom hacked version of Liam Quinn's lq-nsgmls (OpenSP includes Liam's patches).
Add "check.cfg" configuration file to avoid path hacking (replace mjd's regex ;D).
Add first cut at XML output!
Add count of errors found in page.
Add icon for ISO-HTML.
Bring back the Root Namespace in results.

Validator v0.7.0 (tentative)

Core Changes

Investigate how, if, and when, to use Nick Kew's most excellent XMLMessageReporter patch to OpenSP.
Figure out some way to avoid inlining so much static HTML!
Finish up the textarea for testing short HTML fragments.
Add an HTML pretty-printer feature, using tidy and/or Enscript?
Add support for https:// (TLS/SSL) using Ville's patches.
Pay attention to Accept-Charset (cf. this message from "brewhaha").
Double check that all output is valid! In particular, use style rules to specify height/width on suggested links.
Do a great big update of the various badges; the details of size, transparency, naming, and how they are linked to (v.w3.org vs. w3.org).
Make sure we output sane "text/html; charset=foo".

Documentation Changes

Clarify the wording regarding valid characters in errors.html (cf. this message from Clemens Radl. Thanks Clemens!)
Write documentation for the SGML catalog, point out good DOCTYPEs to use, and make it easy to find if your editor won't insert them for you.
Add system requirements for NT/W2K. Bug Bjoern about his "Installing the Validator on NT" doc. Link to ActiveState Text::Iconv and friends.
Add docs on editing DTDs.
Document how to add new DOCTYPEs to the Validator.
Write documentation for Content Negotiation of Badges

Website Changes

Add catalog of online tools and other validators. In particular, link to the WDG tools and Nick Kew's most excellent *Valet tools.
Link to Jukka's pages; both in general and to specific pages. Ask him about mirroring some of the stuff on validator.w3.org.
Include some Bookmarklets for the Validator

Validator v1.0.0 (tentative)

Core Changes

Add a "fix my HTML for me" option using Tidy.
Finish adding support for XML validation (see also: test cases, or an existing service).
Add a section to the report on document cacheability? (or just link to it?)
Put the explanations in a database (flat files are probably OK), and offer an option to display them inline with the errors.
Incorporate CSS validation directly into this service; either directly or by some form of linking to the existing service on Jigsaw.
Make e.g. http://validator.w3.org/check/referer;imgonly return only an image showing the validation status of the referring page.
Add link validation using Hugo's checklink code (or other code with similar functionality).
Add a "document meta-information" section to the report, to encourage people to use META tags appropriately?
Figure out what's going on with this. (Thanks to Marie Taylor-Harper for catching this!).
Investigate validation of RDDL.
Fix directories differing only in name case in sgml-lib/pro/usr/local/lib/sgml/. We have both "ietf" and "IETF" in there.

Documentation Changes

Write documentation, describing each feature and option of the validator and answering questions like "What's the difference between an SGML parser and Weblint?", "Which DOCTYPE should I use?", content negotiation, ...

Website Changes

Update sgml-lib.tar.gz; automate the updates.

Various Unclassified Stuff

These items are roughly in prioritized order; i.e. the items near the top are those which I consider most important.

Make lists of "most frequently validated invalid pages" and "most frequently validated (non-W3C?) valid pages" (need to start logging stuff first, including IPs to compare uniqueness).
Install and play with HTML::Validator, link to it from somewhere: HTML::Validator Home Page Sami Itkonen's CPAN directory
Give errors/warnings related to markup that is technically valid SGML, but error prone, such as things found in "B.3 SGML implementation notes" in the HTML 4.0 spec. (these things really belong in something like Tidy).
Make an "elements found" section a la Webtechs, with links from each element to the appropriate place in either the DTD tree listing produced with dtd2html (after running dtd2html with all DTDs in the catalog), or the HTML 3.2/4.0 specs, or htmlhelp.com stuff, ...
Add a "recommend a DTD for me" feature (check a document against all available DTDs, report which one has the fewest errors)
Start caching validation results locally and doing an If-Modified-Since HTTP request to only download and re-validate URLs if they actually changed since their last validation
Site walker/validator: need to add a "registered user" feature first, because this feature could be abused (many requests on a server in a short period of time)?
URL-minder service: "remind me if this page or set of pages ever ceases to validate".
- "registered user" feature is also necessary for this (to prevent unwanted e-mail)
- "registered users" could have a list of URLs they're interested in, and whenever they return to the service they can modify this list, and e-mail can be sent whenever any of them cease to validate
- Right now someone could probably use the existing URL-minder service instead of writing a new one (tell it to "mind" the URL that points to the validation result for a page?) But I'm not sure how regularly URL-minder checks for changes; it seemed to be weekly or something, which isn't frequent enough, IMO. Doing an If-Modified-Since GET every day doesn't cost much if pages don't change. Some of these features should only be enabled if the page consistently returns a Last-Modified header, maybe.
Provide messages in different languages?
Add a graphical representation of the document's structure, using images mixed with text, or just an image?
Add a section with PICS info?
Issue PICS labels for documents that do/don't conform? Or for editing tools that don't conform?