W3C home > Mailing lists > Public > public-evangelist@w3.org > March 2004

(unknown charset) Re: Best Practices in HTML Re: The use of W3C standards in Denmark Part II

From: (unknown charset) Alex Rousskov <rousskov@measurement-factory.com>
Date: Tue, 9 Mar 2004 10:55:05 -0700 (MST)
To: (unknown charset) Tex Texin <tex@XenCraft.com>
Cc: (unknown charset) public-evangelist@w3.org
Message-ID: <Pine.BSF.4.58.0403091027390.79338@measurement-factory.com>

I agree with Tex. Ideally, there needs to be one validator that is as
complete as possible for a given environment. For example, online
checks could include link checks and HTTP compliance/robustness checks
as an option. If that validator can accept plugins to validate new
things, the validator development can be more distributed. However,
from a validator user point of view, it does not really matter.

I would also add that it would be great if that validator can be
installed as a local library of some kind, to be integrated with
content development and content generation tools. This requirement
implies writing Perl and other wrappers and/or providing a local
service with a simple socket interface.

The output can be a very simple XML output (error ID, location,
informal text), I guess. Sophisticated wrappers can be added in some
environments to provide nice rendering and additional features such as
links to specs.


On Tue, 9 Mar 2004, Tex Texin wrote:

> Karl,
> I guess the gist of what I would be looking for as an author, and as someone
> seeking greater W3C standards compliance, would be a "checker" that is not so
> compartmentalized (eg only does links) and simply reports all possible errors.
> I understand this is a difficult request, but I do think it confuses people
> that they run a validator and yet still undetected and common errors remain.
> Running separately a validator, and a link checker, and an embedded css
> checker, suggests that after a lot of checking, other categories of errors
> still exist and it seems to dilute the value of the effort.
> The solution could be as simple as define a common program interface that
> allows people to integrate checking tools and have one command that verifies a
> page using an extensible list of tools, or perhaps verifies an entire web site.
> Others could then write additional checkers that share the interface (eg i18n,
> wai, or other checkers).
> It would also be easier to integrate checking with authoring tools. (A menu
> item could launch a thorough check.)
> As for your question-
> a) list all requirements- my understanding is many of the needed checks are on
> todo lists...
> I think if a start was made on the list of additional checks people would like
> to have, plenty of input would be offered. ;-)
> b) example of what a validator should work with- I am not sure I understand the
> question.
> Perhaps the description above captures the sense of what I would like.
> My goal is really not much more than than to identify common errors in pages
> with a single tool and not be in the business of collecting multiple tools to
> perform different aspects of what might be considered a single task.
> c) a list for discussion would be good.
> I would like to see 2 types of discussion. Perhaps it should be separate lists.
> 1) list for more thorough and integrated checking tool, as discussed.
> 2) a place for people to discuss obstacles to upgrading to more recent
> standards or to being fully compliant, and potential workarounds or solutions.
> This might help us understand how to eliminate the (perhaps perceived)
> obstacles.
> For example, I have heard the arguments for why authors shouldn't specify a new
> window vs reusing an existing window.
> Nevertheless, I prefer to make the choice in my pages and therefore it is an
> obstacle to moving from transitional to strict dtd. I'd like to discuss
> solutions so I can be strict without giving up something I see as important.
> Note, I am not trying to argue this particular point now, on this list. I am
> giving an example of issues that a discussion list might be useful to develop
> ideas to move people forward more quickly.
> hth
> tex
> Karl Dubost wrote:
> >
> > Le 08 mars 2004, à 14:59, Tex Texin a écrit :
> > > It could be the philosophy behind the validator has changed, but in
> > > Nov. 2002,
> > > I reported that the validator did not check for problems such as links
> > > to
> > > fragments that do not exist. (e.g. <a href="#tex"> with no
> > > corresponding id=tex
> > > or name=tex in the document).
> > > At the time it was stated that it wasn't a priority for the validator
> > > to find
> > > problems such as this, unless it was covered by the DTD. i.e. strictly
> > > speaking
> > > it wasn't a validation problem.
> >
> > I think "link checker" verifies this type of mistakes: internal links
> > of a document
> >         http://validator.w3.org/checklink
> >
> > Would you be interested to
> >         1. make the list of all requirements MUST, MAY, SHOULD, etc included
> > in the HTML Spec. (MUST are already done, see my previous message.)
> >         2. give an example on what do you think a validator should work with
> > such a list. Implementation requirements for the validator to be able
> > to detect or warn users.
> >
> > It can be a collective  effort of the mailing list. Though I'm not sure
> > of the right forum for that? public-qa-dev? www-qa? or here?
> >
> > Olivier, what do you think about it?
> >
> > --
> > Karl Dubost - http://www.w3.org/People/karl/
> > W3C Conformance Manager
> > *** Be Strict To Be Cool ***
> >
> >   -------------------------------------------------------------------------------
> >                  Name: PGP.sig
> >    PGP.sig       Type: application/pgp-signature
> >              Encoding: 7bit
> >           Description: =?ISO-8859-1?Q?Ceci_est_une_signature_=E9lectronique_PGP?=
> --
> -------------------------------------------------------------
> Tex Texin   cell: +1 781 789 1898  mailto:Tex at XenCraft.com
> Xen Master         XenCraft           http://www.XenCraft.com
> Making e-Business Work Around the World
> -------------------------------------------------------------
Received on Tuesday, 9 March 2004 12:55:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:16:18 UTC