W3C home > Mailing lists > Public > www-validator@w3.org > February 2000

Re: XHTML validation bug (false pass)

From: Terje Bless <link@tss.no>
Date: Sun, 20 Feb 2000 09:13:50 +0100
Message-Id: <200002200809.JAA16283@vals.intramed.rito.no>
To: W3C Validator <www-validator@w3.org>
cc: David Brownell <david-b@pacbell.net>
On 19.02.00 at 20:10, David Brownell <david-b@pacbell.net> wrote:

>I just thought I'd note a problem in the XHTML validator.

Well, part of the problem is that it's originally a HTML validator based on
an SGML parser. While SP supports XML, I have the impression that the
support is somewhat weaker then that of, say, expat. Of course, those are
implementation details of the W3C HTML and XHTML Validation Service so they
aren't really relevant, but that's the reason in general I think.

Maybe it's time to put a real XML parser in there...

>Basically, it accepts blank lines before XML/text declarations, which are
>explicitly not permitted in the grammar:  no whitespace before either of
>those, and the same syntax elsewhere in the document body (e.g. after the
>newline) counts as an illegal processing instruction

I'm not really an SGML/XML wizard; could you elaborate? All the actual
validation is passed on to SP, but it's possible we can either force SP to
catch it or do it internally in the pre-processing pass. I'm just not clear
on what it is that is getting passed through that shouldn't be. Is it blank
lines before the "<?xml?>" bit? Whitespace inside multiline processing

>which _must_ cause a fatal error.

Well, in general, throwing fatal exceptions isn't really usefull behaviour
for a validation tool. Is there some reason this should be changed in tis

I'm aware that the XML spec demands that you terminate processing if the
document is not well formed, but should this even be extended to tools
whose aim is to help you _make_ the document well formed? Wouldn't that be
Received on Sunday, 20 February 2000 03:10:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:58:15 UTC