Saxon

Without looking too deeply into the gory detail, I suspect the problem is caused by known weaknesses in the design of the JAXP ContentHandler interface. Specifically, the details of the events that are passed across, especially for namespaces, depend on the property settings of the XML "Parser" (that is, the component that issues the events). But in an application like this, Saxon has no opportunity to confirgure the parser, nor even to discover what these property settings are. We decided therefore to mandate that if an application wants to supply the input using this interface, it is required to conform to our expectations on these settings, and that we wouldn't incur the (significant) cost of verifying what is passed over.

See in particular the Javadoc comments on ReceivingContentHandler:

* <p>The {@code ReceivingContentHandler} is written on the assumption that it is receiving events
 * from a parser configured with {@code http://xml.org/sax/features/namespaces} set to true
 * and {@code http://xml.org/sax/features/namespace-prefixes} set to false.</p>
 * <p>When running as a {@code TransformerHandler}, we have no control over the feature settings
 * of the sender of the events, and if the events do not follow this pattern then the class may
 * fail in unpredictable ways.</p>

There's also a comment on the startElement method:

* <p>This event allows up to three name components for each
     * element:</p>
     *
     * <ol>
     * <li>the Namespace URI;</li>
     * <li>the local name; and</li>
     * <li>the qualified (prefixed) name.</li>
     * </ol>
     *
     * <p>Saxon expects all three of these to be provided.

We also rely on startPrefixMapping() and endPrefixMapping() calls happening.

I strongly suspect that the startNamespacePrefix() and endNamespacePrefix() methods on the ContentHandler are not being called.