Saxon

Am I right in thinking I need to apply c.xsl to form_1.xml and that form_2.xml is the output?

Problem reproduced. I think the problem is not so much that the result tree isn't validated, as the fact that it is incorrectly serialized: the header element is created in no namespace, so it should be serialized with an xmlns="" undeclaration, which would make it valid. I think that somehow the NamespaceReducer which would normally be added to the output pipeline and which would create this undeclaration isn't there, or is in the wrong place in the pipeline relative to the two validators.

There is a NamespaceReducer on the pipeline, but it is not adding the xmlns="" undeclaration because the startElement event has the property NAMESPACE_OK (=64), indicating that the caller asserts that there is no need for the NamespaceReducer to take this action.

The validated element has in fact been placed on a temporary TinyTree (for reasons that might be worth investigating separately...) and is being copied from the TinyTree to the XMLEmitter with copyOptions correctly set to ALL_NAMESPACES.

The code for copying an element from a TinyTree is assuming, I think, that all required local namespace declarations (and undeclarations) are present in the tree. But in this case they are not. In fact, a no-namespace element in a TinyTree build by parsing a source document does not have a local namespace binding for xmlns="" unless the undeclaration was explicitly present in the lexical XML source.

It looks as if this has nothing to do with schema validation. A typeless version of the same transformation also fails to add an xmlns="" declaration to the serialized form of the header element.

In fact the stylesheet can be reduced to a non-schema-aware stylesheet with the single template rule:

   <xsl:template match="/*">
        <xsl:copy>
            <xsl:sequence select="doc('b.xml')/b:request"/>
        </xsl:copy>
    </xsl:template>

to demonstrate the problem: the output is:

<?xml version="1.0" encoding="UTF-8"?>
<form xmlns="test.com/c" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <b:request xmlns:b="test.com/b">
      <header>HEADER</header>
      <b:service>SERVICE</b:service>
   </b:request>
</form>

where the header element is missing an xmlns="" declaration to indicate that it is (or should be) in no namespace.

I think my earlier observation that the problem was not present with the linked tree was incorrect. Running namespace-1901 from the Transform command line with -tree:linked gives the incorrect output.

So I'm now looking at the ComplexContentOutputter / NamespaceReducer combination to see how this should be tackled.

Firstly in CCO startContent we currently skip the checkProposedPrefix() check for a no-namespace element. It seems that this is not safe.

Secondly, in NamespaceReducer.isNeeded(), we decide (after performing various other checks) that a default namespace declaration is not needed. Again, this seems unsafe.

If we make these changes, test namespace-1901 succeeds with both tinyTree and linkedTree. But I strongly suspect this will have side-effects.

Sure enough, test namespace-2608 fails: the output contains a redundant xmlns="" declaration.

It seems the change to NamespaceReducer was unnecessary, and it has been reverted. This appears to give clean test results.