- From: Terje Bless <link@pobox.com>
- Date: Tue, 7 Jan 2003 09:52:25 +0100
- To: QA Dev <public-qa-dev@w3.org>
- cc: Karl Dubost <karl@w3.org>
Karl Dubost <karl@w3.org> wrote: >In the process of being more educative and not making people afraid, I >said it in the past, but I don't remember if Terje thought it would be >difficult to implement :) > >When we validate a Webpage, we have the number of errors which is given, >but not the number of errors type that have been made. > >For example if the tag ALT has been forgotten in the page 43 times, it >means that the same error come again and again :) > >So it could be modified in that way: > >Errors: 80 (3 types of errors) or >Errors: 80 (43 for ALT, 34 for TYPE, 3 no attributes "HEIGHT") > >In the EARL report, it's quite easy with an XSLT, but in the HTML output? If this is "quite easy" with EARL and XSLT I would very much like to see an implementation! The first problem lies in the classification of the some odd hundred possible messages that can be emitted into meaningfull categories -- some of which would change categories depending on the exact context in which they are emitted! -- only then do you get to the implementation problem of identifying each message (being a variable text string) and placing it into these categories. You could of course forego the classification and just count each possible message as its own category, but this still leaves the problem of identifying each message in the output. This can be achieved by "stupid" pattern matching and a table of regex->category patterns, by implementing a message catalog parser that reads OpenSP's .po files, or by trapping OpenSP's message numbers and mapping from these and into categories. My plan for friendlier error messages is currently to do the latter and have a separate -- validator-specific -- catalog of messages indexed by these error numbers (which can, BTW, be shared among all the OpenSP-based Validators if desired). Since OpenSP's error messages are variable, at least the initial implementation would emit the original error message first, with the custom error message appearing as an inline "explanation" (as opposed to replacing the error message). This implementation also facilitates a more robust and maintainable implementation of the linked error explanations and lays some of the groundwork for context-sensitive Tips of the Day. IOW it's not "difficult to implement, it's difficult to implement _right_. :-) -- Interviewer: "In what language do you write your algorithms?" Abigail: English. Interviewer: "What would you do if, say, Telnet didn't work?" Abigail: Look at the error message.
Received on Tuesday, 7 January 2003 03:52:30 UTC