XML Parser Default Namespace vs. XSLT Processor Namespace Interpretation for Repeatable Transformations

Answer the Core Question

When an XML document contains an xmlns="…" declaration, the XML 1.0 spec unambiguously binds all unprefixed element names to that URI. If the declaration is absent, those elements are in the “no‑namespace” state. The problem arises when a parser is configured to be namespace‑aware or not, or when the DOM is serialised in a way that strips the default namespace from the output. XSLT 1.0 match patterns and XPath name tests operate on the expanded name (namespace URI + local name), so any mismatch between the parser’s in‑memory namespace bindings and the namespace URI seen by the XSLT processor will produce different match results.

Criteria a Namespace‑Aware Parser Should Apply

• For an unprefixed element, look for the nearest in‑scope xmlns="…". If found, bind the element’s expanded name to that URI; otherwise bind it to the empty namespace.
• For an unprefixed attribute, always bind to the empty namespace, regardless of any default namespace declaration.
• During DOM construction, preserve the namespace URI in the node’s namespaceURI property or the equivalent SAX event attribute.
• When serialising, emit the default namespace declaration if any element in the tree uses it; otherwise omit it to avoid creating a new namespace binding.

Which XSLT Processors Provide Consistent Handling?

All XSLT 1.0 processors that honour the XML Namespaces 1.0 recommendation and expose the same DOM/SAX model will produce identical results when fed the same input. In practice:

• libxslt 1.1.x and Saxon‑HE 6.x (XSLT 1.0 mode) both treat unprefixed elements according to the rules above.
• Older JAXP/Xalan 2.7.x implementations may exhibit a bug where the default namespace is dropped on DOM serialization, leading to mismatches.
• Any processor that implements the xpath-default-namespace feature (XSLT 2.0+) must be used with an explicit default in the stylesheet, but for pure XSLT 1.0 this feature is absent.

Building a Repeatable Test Harness

1. Parse the XML once with a namespace‑aware parser (e.g., DocumentBuilderFactory.setNamespaceAware(true) in Java). Store the resulting DOM tree.

2. Serialize the DOM using a canonical serializer that preserves namespace declarations (e.g., TransformerFactory.newInstance() with OutputKeys.METHOD=xml and OutputKeys.OMIT_XML_DECLARATION=no).

3. Run the same XSLT 1.0 stylesheet against three input forms:

   • the original XML file (stream input)
   • the DOM tree (DOM input)
   • the serialised DOM string (stream input)

   All three should yield identical byte‑for‑byte output. If they diverge, the culprit is either the parser’s namespace handling or the serializer’s omission of the default namespace.

4. Use namespace-uri() inside the stylesheet to debug the binding of a sample element:

   <xsl:template match="/root/sample">

   Inspect the output to confirm the URI matches the one declared in the source.

5. Cross‑check with a second XSLT processor. If the outputs still differ, the difference is processor‑specific; otherwise the parser/serializer is the source.

What to Verify in Your Environment

• Is your parser configured to be namespace‑aware?
• Does your serializer emit the default namespace declaration for elements that use it?
• Are you using the same XSLT 1.0 processor across all runs, or at least one that follows the XML Namespaces 1.0 spec?

Missing Diagnostic Detail

To give a precise recommendation, I need to know whether your XML parser is currently set to namespaceAware=true (or its equivalent) and whether you’re using a DOM serializer that preserves default namespaces. Could you confirm those settings?