A non-validating processor is NOT required to read
the external subset. I never said it was required
to NOT read the DTD, I said it MUST NOT be an error
if the file specified by the SYSTEM keyword is not
there. Sorry if I was not clear on that point.
A non-validating processor appears to be allowed to
read information from that file if it is there but
it is NOT an exception if it isn't since it
is ABSOLUTELY NOT allowed to use that information
to modify the internal subset in ANY way.
I must admit that I find a lot of the spec. too
ambiguous to be useful so I'm willing to go with
group consensus for the ambiguous parts. I just
don't think this is one of them.
When I read the spec.; that's what it says to me.
Maybe I'm missing something?
-----Original Message-----
From: Dean Roddey [mailto:[EMAIL PROTECTED]]
Sent: Thursday, April 26, 2001 1:32 PM
To: '[EMAIL PROTECTED]'
Subject: RE: PLEASE HELP: SAX parser errors on validation when
ValScheme=V al_Never?????
> A non-validating processor is apparently
> allowed to attempt to read foo.dtd, but
> it MUST NOT be an error if the file is
> not found since a non-validating processor
> is NOT required to read the external sub-set.
Well, that logic isn't exactly ummm...logical :-) The fact that its not
*required* to read the external subset, doesn't mean that its required *not*
to read the subset either.
But anyway, the reason that is is the way it is right now is that there is
no way to report the error. The parser cannot, ever, ever, ever, silently
just ignore the DTD and continue, even if non-val, because the DTD could
very much change the resulting file.
So, we would have to have a way to say "hey, the DTD didn't exist, can I
continue?" But how will we do that? There's no DOM or SAX API to do this.
The only callbacks you use with SAX or DOM are the SAX defined callbacks. So
how can we report the error? We can't throw an exception, since that would
unwind the stack and there would be no way to restart.
If we cannot report the error, then the only way we could support it is by
having you tell us, up front before the parse, that we can unconditionally
ignore the DTD if not found, but that wouldn't suit many people's needs
either, because they don't know that they aren't going to find it.
So its not as easy as it sounds. Anything that we would do would be
non-standard, and non-portable, unless an API was provided to do it. And, in
a way, that API already exists in the form of the entity resolver. That's
one of the things its to be used for.
--------------
Dean Roddey
Software Geek Extraordinaire
Portal, Inc
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
======================= Confidentiality Statement =======================
The information contained in this message and any attachments is
intended only for the use of the individual or entity to which it is
addressed, and may contain information that is PRIVILEGED, CONFIDENTIAL
and exempt from disclosure under applicable law. If you have received
this message in error, you are prohibited from copying, distributing, or
using the information. Please contact the sender immediately by return
e-mail and delete the original message from your system.
===================== End Confidentiality Statement =====================
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
