Have you installed an ErrorHandler to see if there are any problems parsing
the file? It seems to me from your message that you're assuming that the
file was successfully parsed on NT, and the bug is in walking the DOM
instance, but that may not be true.
In particular, you should see if there is some problem opening the DTD file
on NT vs. Win2000. If the document input is coming from a
MemBufInputSource instance, then you might want to try setting an
appropriate system ID on that instance, so that the system ID of the
DOCTYPE can be resolved in a consistent manner. The other option is to
create and install a custom EntityResolver that knows how to resolve the
system ID properly. That's probably a better solution for this sort of
use-case.
You might also try removing the DOCTYPE temporarily, to see if that clears
up the inconsistency between the two platforms.
Dave
Charles
Prosser/Watson/I To: [EMAIL PROTECTED]
BM@IBMUS cc:
Subject: Re: WinNT vs Win2000
02/06/2002 01:34
PM
Please respond
to xerces-c-dev
Hello,
I've downloaded xerces-c1_5_1-win32.zip.
I've had some success using the DOM api to parse an xml message
created by a client and sent to a server. The server reads the message
from the socket into a buffer and parses it using the MemBufInputSource.
I've borrowed heavily from DOMPrint.cpp, modifying the ostream operator <<
function to my needs.
Here is a sample xml message which I dumped to a file:
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE api_msg SYSTEM "api_msg.dtd">
<api_msg>
<head type="2" app_id="40803e4" synch="1"/>
<info>
<client services="1" host="0000018c.0" application="init" version="8.0"
directory="c:/rundir"/>
</info>
</api_msg>
On a Win2000 machine my code successfully parses this message. Here is
some sample
debug output:
Parse: entered.
Node: name #document, value , type 9.
Found DOCUMENT_NODE.
Parsing child of document.
Node: name api_msg, value , type 10.
Found DOCUMENT_TYPE_NODE.
Parsing child of document.
Node: name api_msg, value , type 1.
Found ELEMENT_NODE.
Parsing child of element api_msg.
Node: name #text, value
, type 3.
Found TEXT_NODE.
Parsing child of element api_msg.
Node: name head, value , type 1.
Found ELEMENT_NODE.
Parsing child of element api_msg.
Node: name #text, value
, type 3.
Found TEXT_NODE.
Parsing child of element api_msg.
Node: name info, value , type 1.
Found ELEMENT_NODE.
Parsing child of element info.
Node: name #text, value
, type 3.
Found TEXT_NODE.
Parsing child of element info.
Node: name client, value , type 1.
Found ELEMENT_NODE.
Parsing child of element info.
Node: name #text, value
, type 3.
Found TEXT_NODE.
Parsing child of element api_msg.
Node: name #text, value
, type 3.
Found TEXT_NODE.
Clearly the code has parsed the entire message and walked through all
children of
the document node and any children of the element nodes.
When I run the same code on a Windows NT machine I get the following debug
output:
Parse: entered.
Node: name #document, value , type 9.
Found DOCUMENT_NODE.
Parsing child of document.
Node: name spch_msg, value , type 10.
Found DOCUMENT_TYPE_NODE.
It appears that the code cannot walk through all the children of the
document node.
When processing a document node ( as in DOMPrint.cpp ) the code does this:
case DOM_Node::DOCUMENT_NODE :
{
DOM_Node child = toParse.getFirstChild();
while( child != 0) {
my_parse_node ( child );
child = child.getNextSibling();
}
break;
}
The function getFirstChild returns a valid node which is parsed by
my_parse_node,
but getNextSibling does not return a valid node so the code exits the while
loop.
Can anyone give me any suggestions what may be causing this difference in
behavior between Win NT and Win 2000?
Thanks for your help,
Charles Prosser
---------------------------------------------------------------------
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]
