Next message: Martin Duerst: "Reissuing 'Character Set' Note? Re: Better internationalization of validator"
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: duerst@w3.org
Cc: www-validator@w3.org
Date: Thu, 24 May 2001 00:18:08 +0200
Message-ID: <6vbogtsf4h50rufjn3a1i72bjuipdueqfj@4ax.com>
Subject: Re: Better internationalization of validator
* 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/