W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2006

[whatwg] Update to the Adoption Agency Algorithm

From: Bjoern Hoehrmann <derhoermi@gmx.net>
Date: Sat, 04 Feb 2006 07:24:04 +0100
Message-ID: <aqg8u1lpvhfb35u4k3fsl95mbmbq6elonn@hive.bjoern.hoehrmann.de>
* 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

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:26 UTC