Let me try to clarify Robert's comments a trifle... > When you use setAttributeNS, the DOM creates the namespace nodes but > does NOT create the namespace declaration nodes.
The problem here is that "namespace nodes" are a concept defined by XPath 1.0 but not by the DOM. (It's worth noting that XPath 2.0 is moving away from this concept and toward the idea of a non-node list of namespaces in scope at a given point.) Conversely, namespace delaration attributes are not directly exposed by XPath 1.0, even though namespaces-in-scope/namespace-nodes are. So we have a problem of mixed metaphors. Xylem tries to Do The Right Things when you pass it a namespace-aware DOM, but it's possible we miss some cases. > you have a DOM that is valid internally, but when you > serialize it, some of the namespaces may not have declarations. That should never happen. The serializer is responsible for creating declarations if they haven't been previously established; if it doesn't, it isn't serializing correctly. The one case we _might_ have trouble handling automatically is if you're building up a string value which contains a QName (such as an XPath) and the prefix used in that QName isn't required for other uses. (This is why XSLT's copy operation says namespace nodes get copied by policy rather than trying to determine whether they're needed or not.) Standard reminder, which I think someone else has voiced: Never use namespace-unaware DOM nodes in conjunction with namespace-aware software. Consider createElement(), createAttribute(), and setAttribute() obsolete unless you explicitly need to create a DOM 1.0 model. They are NOT equivalent to the ...NS() versions of these calls with a null namespace URI.
