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

Re: Better internationalization of validator

From: Bjoern Hoehrmann <derhoermi@gmx.net>
Date: Thu, 24 May 2001 00:18:08 +0200
To: duerst@w3.org
Cc: www-validator@w3.org
Message-ID: <6vbogtsf4h50rufjn3a1i72bjuipdueqfj@4ax.com>
* Martin Duerst wrote:
>Hello Gerald, others,
>
>I have just committed a very small patch to the 'check' validating
>script, just to change some terms ('character encoding' rather than
>'character set';

Ah, good catch!

>Over the weekend, I have had an extensive look at the validating
>script, and I have various ideas for improvement in the area of
>internationalization that I will work on in the next few days/
>weeks. I'm looking forward to your comments/suggestions.

I don't know if it's worthwile to spend a larger amount of time on the
current code base. I think we will have some major changes in the near
future. I hope we can give the check script a little more structure.

Terje, possible Gerald and I currently investigate some XML
parsers/validators that could be integrated into the HTML Validator
since SP provides only limited support for XML documents and is
therefore not that usable. If you take a look into the archives of
www-validator-css@w3.org (the CSS validators uses a real XML parser)
you'll see, that those limitations cause a lot of confusion and this
will get worse in the future. I also expect that a XML Schema Validator
should be incorporated into the W3C Validator, something useful and
someday needed for XHTML beyhond m12n with DTD modules.

I suggest a generic interface to these validators with several drivers
in the backend, e.g.

    W3C::Validator::Parser::RXP
    W3C::Validator::Parser::SP
    W3C::Validator::Parser::XSV

"implement" a generic

    W3C::Validator::Parser

interface. The output (typically line/column number and an error
message) could than be passed to the script via events or perl lists and
presented to the user.

The presentation (i.e. XHTML-output) should be done via templates (Terje
says ;-) If some template driver receives the data in a generic fashion
it should be easy to maintain i18n issues.

The third (or better first :-) part cares about the input (fetch
document via URI, textfield, uploaded file, etc.)

etc.

As I said, maybe the whole script would be rewritten, to cobble the
current script might not be a good idea. Maybe we should focus some
specific goals and work on a check 2.0?

What would you put on our todo list?
-- 
Björn Höhrmann { mailto:bjoern@hoehrmann.de } http://www.bjoernsworld.de
am Badedeich 7 } Telefon: +49(0)4667/981028 { http://bjoern.hoehrmann.de
25899 Dagebüll { PGP Pub. KeyID: 0xA4357E78 } http://www.learn.to/quote/
Received on Wednesday, 23 May 2001 18:17:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 25 April 2012 12:13:58 GMT