They would absolutely very much want to know that, because it could
drastically change the resulting document. If I have a complex file that is
made up of many documents, but I don't have a DTD and therefore cannot
validate, then I definitely do not want the parser to just silently skip
over any entities that it thinks weren't defined because, in my application,
that is a serious error. It should be under user control as to whether such
things are considered fatal or not, and not all the way at the end of the
document. There must be a way to know right then and there and tell the
parser whether to go on.

--------------
Dean Roddey
Software Geek Extraordinaire
Portal, Inc
[EMAIL PROTECTED]



-----Original Message-----
From: Bil Mason [mailto:[EMAIL PROTECTED]]
Sent: Thursday, April 26, 2001 7:22 AM
To: [EMAIL PROTECTED]
Subject: RE: PLEASE HELP: SAX parser errors on validation when ValScheme=V
al_Never?????


Hmm.  I think it should only be an exception when
validating.  I can't imagine why the user of a non-
validating processor would care if an external reference
existed or not but maybe the parser should have some sort
of warning flag that could be checked after a parse to
signal that situation.

-----Original Message-----
From: Peter A. Volchek [mailto:[EMAIL PROTECTED]]
Sent: Thursday, April 26, 2001 10:10 AM
To: [EMAIL PROTECTED]
Subject: Re: PLEASE HELP: SAX parser errors on validation when
ValScheme=Val_Never?????


Absolutely agree

>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.

Lets say, it must not be a critical error, in other words, one should be
able to catch exception and continue parsing.
Sometimes it is desirable to know that dtd is missing.

----- Original Message ----- 
From: Bil Mason 
To: [EMAIL PROTECTED] 
Sent: Thursday, April 26, 2001 5:00 PM
Subject: RE: PLEASE HELP: SAX parser errors on validation when
ValScheme=Val_Never?????


Actually, I don't think it's quite that simple.  A non-
validating parser is NOT required to read the external
subset at all.  Unfortunately, the 1.0 spec. doesn't say it
MUST not, only that "Non-validating processors are required
to check only the document entity, including the entire
internal DTD subset, for well-formedness." (REC-xml-20001006
5.1, para. 4)  The problem seems to be that processors are
allowed to read external declarations, but they can NOT use
them to modify the internal sub-set.

At any rate, Chris said "... when I parse an xml doc that
specifies a dtd ...".  It sounds to me like he might have
meant he has a document that has a line like this:

<!DOCTYPE foo SYSTEM "foo.dtd">

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.


-----Original Message-----
From: Erik Rydgren [mailto:[EMAIL PROTECTED]]
Sent: Thursday, April 26, 2001 7:07 AM
To: [EMAIL PROTECTED]
Subject: RE: PLEASE HELP: SAX parser errors on validation when
ValScheme=Val_Never?????


Yes that is the correct behaviour.
The DTD can contain definitions that are needed even when not validating.

/ Erik Rydgren


-----Original Message-----
From: Prior, Chris [mailto:[EMAIL PROTECTED]]
Sent: den 26 april 2001 13:00
To: '[EMAIL PROTECTED]'
Subject: PLEASE HELP: SAX parser errors on validation when
ValScheme=Val_Never?????


Hi all,

I am using the SAX parser and setting validation to Val_Never, yet when I
parse an xml doc that specifies a dtd the parser fails if it cannot find the
dtd!!!

Why is this the case when I am not interested in validating? Surely looking
for the dtd when no validation is required is not correct?

Please help!

Chris







======================= 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]

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to