title: Doing DOM Node-to-String transformation, but with namespace issues
body: <p>So we have an XML Document with custom namespaces.  (The XML is generated by software we don't control.  It's parsed by a namespace-<em>unaware</em> DOM parser; standard Java7SE/Xerces stuff, but also outside our effective control.)  The input data looks like this:</p>
  
  <pre><code>&lt;?xml version="1.0" encoding="ISO-8859-1" standalone="no"?&gt;
  &lt;MainTag xmlns="http://BlahBlahBlah" xmlns:CustomAttr="http://BlitherBlither"&gt;
      .... 18 blarzillion lines of XML ....
      &lt;Thing CustomAttr:gibberish="borkborkbork" ... /&gt;
      .... another 27 blarzillion lines ....
  &lt;/MainTag&gt;
  </code></pre>
  
  <p>The Document we get is usable and xpath-queryable and traversable and so on.</p>
  
  <p>Converting this Document into a text format for writing out to a data sink uses the standard Transformer approach described in a hundred SO "how do I change my XML Document into a Java string?" questions:</p>
  
  <pre><code>Transformer transformer = TransformerFactory.newInstance().newTransformer();
  transformer.setOutputProperty(OutputKeys.OMIT_XML_DECLARATION, "no");
  transformer.setOutputProperty(OutputKeys.INDENT, "yes");
  StringWriter stringwriter = new StringWriter();
  transformer.transform (new DOMSource(theXMLDocument), new StreamResult(stringwriter));
  return stringwriter.toString();
  </code></pre>
  
  <p>and it works perfectly.</p>
  
  <p>But now I'd like to transform individual arbitrary Nodes from that Document into strings.  A <code>DOMSource</code> constructor accepts Node pointers just the same as it accepts a <code>Document</code> (and in fact Document is just a subclass of Node, so it's the same API as far as I can tell).  So passing in an individual Node in the place of "theXMLDocument" in the snippet above works great... until we get to the <code>Thing</code>.</p>
  
  <p>At that point, <code>transform()</code> throws an exception:</p>
  
  <pre><code>java.lang.RuntimeException: Namespace for prefix 'CustomAttr' has not been declared.
      at com.sun.org.apache.xml.internal.serializer.SerializerBase.getNamespaceURI(Unknown Source)
      at com.sun.org.apache.xml.internal.serializer.SerializerBase.addAttribute(Unknown Source)
      at com.sun.org.apache.xml.internal.serializer.ToUnknownStream.addAttribute(Unknown Source)
      ......
  </code></pre>
  
  <p>That makes sense.  (The "com.sun.org.apache" is weird to read, but whatever.)  It makes sense, because the namespace for the custom attribute was declared at the root node, but now the transformer is starting at a child node and can't see the declarations "above" it in the tree.  So I think I understand the problem, or at least the symptom, but I'm not sure how to solve it though.</p>
  
  <ul>
  <li><p>If this were a String-to-Document conversion, we'd be using a <code>DocumentBuilderFactory</code> instance and could call <code>.setNamespaceAware(false)</code>, but this is going in the other direction.</p></li>
  <li><p>None of the available properties for <code>transformer.setOutputProperty()</code> affect the namespaceURI lookup, which makes sense.</p></li>
  <li><p>There is no such corresponding <code>setInputProperty</code> or similar function.</p></li>
  <li><p>The input parser wasn't namespace aware, which is how the "upstream" code got as far as creating its Document to hand to us.  I don't know how to hand that particular status flag on to the transforming code, which is what I really would like to do, I think.</p></li>
  <li><p>I <em>believe</em> it's possible to (somehow) add a <code>xmlns:CustomAttr="http://BlitherBlither"</code> attribute to the Thing node, the same as the root MainTag had.  But at that point the output is no longer identical XML to what was read in, even if it "means" the same thing, and the text strings are eventually going to be compared in the future.  We wouldn't know if it were needed until the exception got thrown, then we could add it and try again... ick.  For that matter, changing the Node would alter the original Document, and this really ought to be a read-only operation.</p></li>
  </ul>
  
  <p>Advice?  Is there some way of telling the Transformer, "look, don't stress your dimwitted little head over whether the output is legit XML in isolation, it's not going to be parsed back in on its own (but you don't know that), just produce the text and let us worry about its context"?</p>