Re: XHTML validation bug (false pass)

On 20.02.00 at 08:22, David Brownell <david-b@pacbell.net> wrote:

>I don't know what you mean by "passed through"

As in "is not flagged as an error, but should be".


>the following isn't reported as a fatal error:
>   Line 1:     
>   Line 2:     <?xml version="1.0"?>
>   Lines 3-N:  irrelevant

Ok, so it's a blank line before the XML PI(?) that isn't flagged by the
validator, but which should be? We can catch that manually if our parser
won't do it on it's own. Is this the only place this should be taken into
account or are there pitfalls like this anywhere else in a XML document?


>It does make me wonder how many other illegal XML constructs are passing
>through there.

Me too. :-(


>Has anyone run the OASIS/NIST XML test cases against the processor you're
>using?

Not that I know of. The W3C are using James Clark's SGML parser nsgmls,
which has some support for XML in version 1.3, but I don't know enuogh
about XML to judge how much or how well. XML support in the Validator is
still labelled as Experimental.


>I've got an updated copy, which a few folk have sanity checked.

Can this be got from the usual suspects (oasis-open etc.)?


>>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 case?
>
>To report the error?  Absolutely -- it's telling folk that seriously
>broken XML is valid, when it's not even well formed. [...] The XML spec
>actually demands that you stop reporting anything except errors ...

IIRC, the XML spec sez that any well formedness error is fatal (as in dead
stop!), but that any validity errors can be reported if normal processing
is stopped. Today, the validator will report any error, but continue
processing and report any further errors; regardless of whether the error
was one of Validity or Well Formedness. Do you think the Validator should
stop processing after reporting the first Well Formedness error or should
it attempt to keep going and report as many errors as possible?

Under no circumstances should it claim that a document is valid and well
formed if it isn't actually both, but I'm not certain whether it should
terminate on some errors and keep checking on others.


>Of course, after the first non-recoverable error, any other error report
>will be questionable ...

Yes, this is a problem even in HTML validation.

What is more usefull, a message that sez "I cannot check this document
because it isn't well formed" or a bunch of error messages that may or may
not be real errors except for the very first one? I'm leaning towards the
latter, but IIRC the XML spec mandates the former. Anyone have some light
to shed? Insights? Opinions?

Received on Sunday, 20 February 2000 14:51:05 UTC