: : Node.ATTRIBUTE_NODE case so it is treated the same as TEXT_NODE and it : : works for resin and the tests pass. : : Hmmm... yeah, this seems to be a mistake in the DOM-Level-3-Core : description of what getText is suppose to do ... it says that for : ATTRIBUTE_NODE you should concat all of the children -- but how would an : ATTRIBUTE ever have children?
Did some more reading ... according to DOM-Level-3-Core, an Attr's allowed children are "Text" and "EntityReference". Xerces2-j NodeImpl..getTextContent duplicates the table from the Level-3-Core docs (which is also in the java 1.5 javadocs for org.w3c.dom.Node.getTextContent()) which the notable exception that they move ATTRIBUTE_NODE down into the second row (indicating nodeValue should be used instead of concating the children) ... the impl backs this up (AttrImpl inherits getTextContent from NodeImpl, which by default returns this.getNodeValue()) http://xerces.apache.org/xerces2-j/javadocs/xerces2/org/apache/xerces/dom/NodeImpl.html#getTextContent() http://java.sun.com/j2se/1.5.0/docs/api/org/w3c/dom/Node.html#getTextContent() http://svn.apache.org/viewvc/xerces/java/trunk/src/org/apache/xerces/dom/AttrImpl.java?view=markup http://svn.apache.org/viewvc/xerces/java/trunk/src/org/apache/xerces/dom/NodeImpl.java?view=markup Fortunately, the DOM Spec says that accessing the Attr.nodeValue is defined to be Attr.value, which is documented as... On retrieval, the value of the attribute is returned as a string. Character and general entity references are replaced with their values. ...so even if someone out there is acctually obeying the spec about giving Attr's child nodes, we should still be safe using getNodeValue in the Node.ATTRIBUTE_NODE case since the spec says that needs to work too. -Hoss
