- From: Bjoern Hoehrmann <derhoermi@gmx.net>
- Date: Sat, 04 Feb 2006 07:24:04 +0100
* Ian Hickson wrote: >On Fri, 3 Feb 2006, Blanchard, Todd wrote: >> You are assuming that validators run javascript - they generally don't. >> I'm hoping to add it to Scrutinizer >> (http://www.blackbagops.net/seaside/html) but that would make it unique >> in the world of validators. > >It's mathematically impossible to verify that all script on the page is >always going to generate conformant DOMs, but indeed, a validator that >attempts it should be given high marks. Well, if you approach the problem by asking whether it's possible that things become non-compliant, you'll either have to analyze any and all dependencies like server-side scripts and workflows or you'd generate false negatives, since adding some external data to the document is very likely to generate errors if the external data is non-compliant. The right approach here is to extend implementations to perform validation, e.g. after each mutation event. That's in fact trivial to implement and has already been done. It would not be fast though, and should probably be combined with code coverage analysis but it's about as close as you can get to the extend relevant to developers. We already have several browser extensions like the HTML Tidy extension for FireFox that do something close to that, before too long we'll also have extensions that support RELAX NG, XML Schema data types, Schematron and some extensions like DTLL or custom XPath functions combined with some NVDL (since that would just require a simple wrapper to existing implementations); you'd just bind that to some events and are almost there. I also note that the various DSDL technologies are extremely powerful, there is little that can't be checked that way (complex micro grammars with middle recursion or grammars that require significant post-processing like checking strings after removing escape sequences come to my mind, along with non-machine testable requirements like that certain things must be in a specific natural language). Of course, all of that would be signiciantly simpler if implementations simply validate as appropriate, they have to implement most if not all relevant things anyway. But given browser vendors don't want to be talked into that, we'll have to work around. Of course, errors are very expensive in any case, it's best to design new technology such that there is only a minimum of possible errors. -- Bj?rn H?hrmann ? mailto:bjoern at hoehrmann.de ? http://bjoern.hoehrmann.de Weinh. Str. 22 ? Telefon: +49(0)621/4309674 ? http://www.bjoernsworld.de 68309 Mannheim ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/
Received on Friday, 3 February 2006 22:24:04 UTC