W3C home > Mailing lists > Public > public-qa-dev@w3.org > January 2006

Re: Validator modularization: any underlying code?

From: Dominique Hazael-Massieux <dom@w3.org>
Date: Wed, 18 Jan 2006 15:44:52 +0100
To: Bjoern Hoehrmann <derhoermi@gmx.net>
Cc: public-qa-dev@w3.org
Message-Id: <1137595492.18335.88.camel@cumulustier>
Hi Björn, and thanks for the quick reply,

Le mercredi 18 janvier 2006 à 15:07 +0100, Bjoern Hoehrmann a écrit :
> >At first, I was thinking to build some ad-hoc system, based on python or
> >XSLT, but if there is existing code to work on top of the validator
> >modularization plans [2], I would probably consider writing the stuff in
> >Perl... So, obviously the question is: is there any code backing up that
> >plan?
> 
> What you can do with XSLT you can probably also do using one of the
> Document Schema Definition Languages from http://www.dsdl.org/ i.e.
> RELAX NG, Schematron, SVRL, DTLL, etc. I would recommend using those
> as much as possible.

I was actually thinking of XSLT mainly for aggregating the results of
other tests; I may also use it for some of the tests themselves, for
infrastructure reason (i.e. we do have an XSLT servlet, but we don't
have a RELAX NG validator set up); Schematron may prove a useful
intermediate, though.

>  Where you can't you'll have to implement custom
> logic somehow; if interoperability with the Validator is a concern,
> we'd need some interface for that. Which we don't have at the moment.

I guess interoperability with the Validator is not a primary concern,
but having it would be better than not.

> Perhaps you could describe what you were thinking of in more detail?

Let me try; the best practices recommend a whole bunch of things, some
that are at the markup level, but many more that are at a different
level. A few examples:
* of course, the document must be valid and use valid CSS (for which my
validator would probably use either the SOAP or the HTTP interface of
the existing validators)
* the total size of the markup and images must not exceed 20 Ko for the
so-called baseline device; this means the tool will have to do some
spidering as the linkchecker does
* the HTTP resources must have cacheability information; this means
doing again some analysis and tests at the HTTP level
* the images should not exceed certain dimensions
* some markup characteristics (use of accesskeys, image maps, etc

Dom
-- 
Dominique Hazaël-Massieux - http://www.w3.org/People/Dom/
W3C/ERCIM
mailto:dom@w3.org

Received on Wednesday, 18 January 2006 14:45:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 19 August 2010 18:12:46 GMT