In addition to the bug fixes, the most visible change is that “validator.creativecommons.org”:http://validator.creativecommons.org now uses the same style sheet and layout as the “creativecommons.org”:http://www.creativecommons.org. A minor (and some would argue irrelevant) change, to be sure, but the difference has been bothering me for a while, so I took great pleasure in crossing that particular task off my list.

If you do find a bug in ccValidator, you can “email”:/contact me, just be sure to include the RDF or URI you’re trying to validate.

So what’s changed? A lot. First, I’m now using the “Quixote”:http://mems-exchange.org/software/quixote framework. This has been a generally positive move: the output.py module that existed previously has been removed, and the HTML generation is a lot less “magic”. I’m also using the new rdfExtract classes (which have, incidently, been rolled in with ccRdf in CVS). Finally, the reorganization around Quixote has allowed the validator to become much more modularized: instead of a bunch of Python that executes as a CGI, there is now a CGI driver and a Python package which can be anywhere in the Python path. Quixote also allows the validator to run under “mod_python”:http://www.modpython.org/, FCGI and as a standalone process.

The plan is to have a test instance up by the end of the week, and a long period of coexistance with the existing stable instance. Eventually, though, the new validator will replace the existing one. I haven’t cut a release yet, but the code is available in “CVS”:http://yergler.net/cvs/viewcvs.cgi/ccvalidator2/ (the module is now ccvalidator2).

So I’m currently working on refactoring the validator to use Quixote. The goals that I’m working toward include a cleaner code layout, semi-transparent (or at least more Pythonic) HTML escaping (which Quixote, with the possible addition of “Nevow”:http://www.divmod.org/Home/Projects/Nevow/ will provide), and support for multiple methods of RDF extraction.

The last item is where much of the work is being invested. The current RDF extraction technique (which uses simple regexes) was borrowed by the “Creative Commons Search engine”:http://search.creativecommons.org/. This simple borrowing demonstrates that there’s a need for a straightforward way to extract RDF from documents, regardless of application. In order to facilitate that in ccValidator and the search engine, I’m working on a pluggable text extraction class, rdfExtract (working title). Hopefully I’ll have a new beta of the validator up later this week which will be easier to maintain and extend.

Comments, criticism and suggestions are “welcome”:http://www.yergler.net/contact, as always.

This release is mainly a syncronization release; ccValidator now uses the “ccRdf”:http://yergler.net/projects/ccrdf core. Porting ccV to this architecture simplified many areas of the code, and provided an excellent test bed for ccRdf. I found a few bugs, and made a few improvments, so there will be a release of ccRdf soon to finish up the syncronization of work.

In addition to ccRdf, ccValidator now sports its own validation image. If RDF parsed from a URL validates properly, you’ll be provided with a bit of HTML to allow you to link to the validation results. Cool, huh? Thanks to Mike L. for the idea.

Thanks for the feedback from all my testers; “let me know”:http://www.yergler.net/pages/contact if you encounter any problems or have any suggestions.

I’d love it if you could try it out at “http://yergler.net/projects/ccv-cvs”:http://yergler.net/projects/ccv-cvs. I’d appreciate hearing any feedback about your experience with it. If things are working as expected, you shouldn’t see any difference between the output you get from the “test instance”:http://yergler.net/projects/ccv-cvs and the output you get from the “production instance”:http://yergler.net/projects/ccvalidator. Thanks for all your help.

I’ve also created a CVS repository for my projects, including ccValidator. You can browse it via the web at “http://www.yergler.net/cvs”:http://www.yergler.net/cvs. I’m unable to offer pserver access with my webhost, so I’ll be adding a cron job to produce nightly tarballs real soon now.

Of course, ccValidator “just happens” to support magnets; if it sees something that looks like a Magnet URN, it constructs a magnet link from it. This leads me to my second point, that I’ve once again updated “ccValidator”:http://www.yergler.net/projects/ccvalidator. The changes and fixes are relatively few. Magnets are now constructed to also contain an optional dn, or Display Name, parameter. The display name is extracted from the dc:identifier tag in the work metadata. Also, the validator won’t barf now if it gets an error code when retrieving the URL (404, etc).

Have fun with it, and as always, feedback is welcome.