W3C home > Mailing lists > Public > www-validator@w3.org > March 2009

Re: Peculiar error count

From: Lou King <lking@knob.com>
Date: Sat, 28 Feb 2009 23:37:27 -0500
Message-ID: <49AA1107.4080702@knob.com>
To: www-validator@w3.org

Paul Nelson wrote, On 2/28/2009 7:07 PM:
>    No problem--making light of it might be the most realistic approach 
> after all.
>    The 'cascade' of errors really can be amazing, this just happened 
> to be the most extreme case I've come across. I wasn't thinking of a 
> mind-reading program (how much harder to write?) so much as a 
> differentiated count at the top of the report, perhaps just separating 
> out the number of errors from the instances of XML parsing errors that 
> go with them. (I believe in a variation of the theme it's occasionally 
> given as x number of errors and y number of 'warnings' ... which also 
> sounds odd, come to think of it.) I wouldn't want to get rid of any of 
> it, just have a better notion in advance of the scope of the problem.
>    Of course, I felt very proud of myself, knocking off 14 'errors' in 
> a single stroke ... but must admit that the 'error' was very clearly 
> identified, I could hardly have missed.
>    Thanks for the response -- Paul
> ----- Original Message ----- From: "Lou King" <lking@knob.com>

Examples are tough, but what the parser though you meant would change 
which following errors were "new" or part of the resulting cascade.

Take something like spell/grammar checker (I couldn't live without 
them).  If the parser comes across "theare" depending on whether you 
should have typed, 'there', 'their' or 'they're' it would have an impact 
on the errors that followed. Depending on what you meant, different verb 
errors or agreement between subject and object, etc - all those things 
my english teachers tried to teach me could show up as error or not.

Of course if what you meant was 'theatre' which were "cascade" errors 
and which were not would be entirely different.  I guess what I'm trying 
to say is that it is easer for you, with fore-knowledge of intent, to 
identify derived errors than it is to write a algorithm guess what was 
meant and look forward into the file and decide which errors are which 
with any assurance.  When the parser detects an error it normally throws 
away all of the syntax until it gets back to good code then starts 
again. This is much similar than keeping track of all the possible what-ifs.

Received on Sunday, 1 March 2009 04:38:12 UTC

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