MarkUp Validation Service

This page has the to-do list for the W3C MarkUp Validation Service, including bugs that need fixing and general wish list items. See also the www-validator mailing list archives for recent discussion that may not be reflected on this page.

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 are removed (see What's New and CVS for details) or moved to the next release if delayed.

Validator v0.7.0

Core Changes

Documentation Changes

Website Changes

Validator v1.0.0 (tentative)

Core Changes

Documentation Changes

Website Changes

Various Unclassified Stuff

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

  1. 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).
  2. Install and play with HTML::Validator, link to it from somewhere: HTML::Validator Home Page Sami Itkonen's CPAN directory
  3. 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).
  4. 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, ...
  5. Add a "recommend a DTD for me" feature (check a document against all available DTDs, report which one has the fewest errors)
  6. 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
  7. 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)?
  8. 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.
  9. Provide messages in different languages?
  10. Add a graphical representation of the document's structure, using images mixed with text, or just an image?
  11. Add a section with PICS info?
  12. Issue PICS labels for documents that do/don't conform? Or for editing tools that don't conform?
  13. Investigate possibility of modifying OpenSP's messages for e.g. invalid attributes to include name of current element and version and type of markup in use.
Valid XHTML 1.0! The W3C Validator Team
$Date: 2002/12/01 11:34:03 $