<?xml version='1.0'?>
<!DOCTYPE addressbook [
<!ELEMENT addressbook (person)*>
<!ELEMENT person (name, email)>
<!ELEMENT name (#PCDATA)>
<!ELEMENT email (#PCDATA)>
<!ATTLIST person gender CDATA #IMPLIED>
<!ATTLIST person location CDATA #IMPLIED>
]>
<addressbook>
<!--beginning of document-->
<person gender="Male" location="South">
<name>
<![CDATA[ <<<John Doe>>>&lt; ]]>
</name>
<email>john@doe.com
</email>
</person>
<person gender="Female">
<name>Jane Doe</name>
<email>jane@doe.com</email>
</person>
<person>
<name>Mary Doe</name>
<email>mary@doe.com</email>
</person>
</addressbook>
 
Sun Parser IBM Parser
Internal DTD It is not displayed by the Document object tree The name of DTD is display right after #document node
External DTD It is not displayed by the Document object tree It is not displayed by the Document object tree
Comment It is not displayed by the Document object tree The content of the comment is shown as a leaf by the Document object tree.
CDATA It is not implemented. This node is displayed as a Text node. Properly displayed as a CDATASection node.
Attribute The String represenation of getAttributes() displays name and its value The String represenation of getAttributes() displays value in square brackets. 
Carriage Return Carriage returns between elements are ignored Carriage returns between elements are displayed as a Text node

ibm and DTD vs sun and DTD

Internal DTD is used, IBM parser displays the DTD as a branch on the Document object tree, but Sun parser does not display it at all.  Further analysis show that nodes returened by the IBM parser does not comform to w3c's recommendation.  For instance, the following part of DTD:
    <!ELEMENT email (#PCDATA)>
    <!ATTLIST person gender CDATA #IMPLIED>
 Element declaration:  nodeName(#element-declaration), nodetype(20);
Attribute declaration:  nodeName(#attribute-definition-list), nodetype(21);
The node names nor the nodetypes are not found at w3c's XML 1.0 recommendation spec.

External DTD is used, both IBM and Sun parser will not display the DTD on the Document object tree.

Analysis
Don't let your program to depend on extracted imformation about DTD using IBM parser since moving to other parser may make your program not to work.

ibm and attribute vs sun and attribute

The string representation of the NamedNodeMap returned by calling getAttributes() from Element node interfaces is displayed differently.  For example, this is a part of XML document above:
    <person gender="Male" location="South">
Sun parser displays getAttributes as follows:
    gender="Male" location="South"
IBM parser displays getAttributes() as follows:
    [Male South]

If an Element node does not contain any attribute, Sun parser displays nothing; however, IBM parser displays an empty square brackets.

Analysis
There is not difference in extracting attribute from an Node.

ibm and comment vs sun and comment

IBM parser display a comment as a leaf on the Document object tree, but Sun parser will ignore the comment.
Analysis
Don't let your program to depend on extracted information about comment using IBM parser since moving to other parser may make your program not to work.

ibm and CDATA vs sun and CDATA

Sun parser forgot to implement CDATASection interface.  Sun parser will treat CDATA as a Text node.  However, IBM parser implemted CDATASection properly.
Analysis
Although Sun parser implemented CDATASection node as a Text node, there is no difference in getting value from the node compare to IBM parser since CDATASection interface is empty and it extends Text node.
Typecasting CDATA value node as a CDATASection node in Sun throws a class type cast exception.

ibm and a carriage return vs sun and a carriage return

IBM parser displays carriage returns between elements as a text node on the Document object tree.  However Sun parser ignore carriage returns between elements.
Analysis
Don't let your program depend on the specific child node, since the number of child node return by IBM and Sun parser is different depend on a carriage return between elements.