PMTo: [EMAIL PROTECTED]Subject: Re: Error vs
FatalError Currently, there is an
option that can be set: 'setExitOnFirstFatalError'. If it is not
set, the parser will not exit when a fatal error is encountered.
So, if we make validation constraints just errors, you are s
we should always make it strict by default.--
Dean Roddey
Software Geek Extraordinaire
Portal, Inc
[EMAIL PROTECTED]
-Original
Message-
From: Khaled Noaman [mailto:[EMAIL PROTECTED]]
Sent: Thursday, April 26,
2001 11:58 AM
To: [EMAIL PROTECTED]
Subject: Re: Error vs FatalError
It
should be made optional if we are going to do it. So we could make the default
the most restrictive, and have the option of telling it to be more lax if that
is desired. I think we should always make it strict by
default.
-- Dean Roddey Software Geek
Extraordinaire Portal, In
age-From: Khaled Noaman
[mailto:[EMAIL PROTECTED]]Sent: Jueves, 26 de Abril de 2001
02:58 p.m.To: [EMAIL PROTECTED]Subject: Re:
Error vs FatalError
Currently, all validation
errors are considered fatal errors, and the parser will exit after the first
broken validation constratint. Guys,
Currently, all validation errors are considered fatal errors, and the
parser will exit after the first broken validation constratint. Guys, I
would like to know your opinion on making validation constraint violation
just errors, and modify the XMLValidator to throw only when fatal errors
are enco
The xerces behaviour - at least it?s worked in this way for me - is that a
broken validation
constraint IS reported and resolved by the error() Handler interface method,
BUT if you Do nothing in the error() Handler then the parser EXIT.
If you want the parser to continue AFTER a broken validation
To get details of why a parse failed, you have to write and plug in an
error handler object. The default handler just fails silently.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED
