W3C home > Mailing lists > Public > www-validator@w3.org > August 2001

Re: Suggestion: Check elment first, attribute second

From: Nick Kew <nick@webthing.com>
Date: Sat, 4 Aug 2001 16:36:25 +0100 (BST)
To: Lloyd Wood <l.wood@eim.surrey.ac.uk>
cc: www-validator@w3.org
Message-ID: <Pine.BSF.4.21.0108041626580.441-100000@fenris.webthing.com>
On Fri, 3 Aug 2001, Lloyd Wood wrote:

> > So in the line
> >          <csobj w="208" h="77" t="Button">
> >                       1      2          34
> > events triggering parser messages are generated at 1, 2, 3 and 4 in
> > that order.
> It strikes me that the perl script could use nested lists and <SMALL>
> to split these out; unknown tags (csobj or 0 in the above
> example) would show up in the leftmost column, and it would be clear
> that fixing something in the outermost list (an unknown csobj) would
> probably deal with items in lists further in (all the unknown tags) -
> even if they are reported first.

But the Perl script doesn't really have the information with which
to make the connections between the different messages it 'sees'
from SP.  Reconstructing the information falls somewhere between
a major new parser and an AI project.  Or did, until last month...

> A single long list of bullet points doesn't really pass on this kind
> of structural information;

But the structural information isn't there in the SP output to start with!

This is the exact problem that my new module generating SP messages
in XML has addressed.  Subject to round tuits (not mine - I don't
have permissions to work on validator.w3.org), this will enable
the validator to present structural information in its messages.

>  I've never found the 'Error: start tag was
> here' to be much use.


Nick Kew

Site Valet - the essential service for anyone with a website.
Received on Saturday, 4 August 2001 11:59:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 14:17:30 UTC