Saxon

The base URI is not being set (or is being set to null) for an element node that is created using the built-in shallow copy template. In this case (assuming the resulting node is parentless), the base URI of the original node should be retained.

The immediate cause is that in TinyBuilder.startElement(), the code that sets base URI has been changed:

Old code

//        if (!pipe.isLocationIsCodeLocation() && location.getSystemId() != null) {
//            tt.setSystemId(nodeNr, location.getSystemId());
//        } 

New code:

        if (isUseEventLocation() && location.getSystemId() != null) {
            tt.setSystemId(nodeNr, location.getSystemId());
        }

That is, the decision to copy the systemId of the event location to become the base URI of the new element node now depends on a setting on the Builder, rather than a setting on the PipelineConfiguration.

The reason for the change was to fix a problem connected with the base URI of nodes derived from xi:include processing. I'm afraid that the algorithms for computing base URI are very fragile; the rules are highly contextual and it's hard to get all the right information to the right place to make the necessary decisions.

The code for explicit construction of element nodes (e.g. using xsl:element or xsl:copy) has this logic:

            if (elemOut.getSystemId() == null) {
                elemOut.setSystemId(getNewBaseURI(context, copiedNode));
            }

and I suspect we need the same thing for built-in template rules. In the case of xsl:copy, getNewBaseURI() returns the base URI of the source node. The logic here is that the base URI for the receiver, and hence for the whole constructed tree, is determined by the base URI of the outermost element, so it is set for the receiver if no base URI has already been set for a parent node.

However, this logic feels incorrect for the case where we are copying a sequence of element nodes that have different base URIs -- it looks to me as if the result nodes will all take their base URI from the first one. Perhaps this needs (yet another) test case.

Adding the logic to initialize systemId of the receiver fixes the supplied test case, but unfortunately my suspicions are confirmed that it only works for the first top-level element in a sequence. If I change the test to:

      <xsl:template as="element(test)" match="document-node()">
		<xsl:variable name="baa" select="doc('baa.xml')/*"/>
		<test>
			<xsl:for-each select="element(foo)">
				<original1>
					<xsl:value-of select="base-uri()" />
				</original1>
				<original2>
					<xsl:value-of select="base-uri($baa)" />
				</original2>

				<xsl:variable as="element(*)*" name="built-in">
					<xsl:apply-templates mode="built-in-shallow-copy" select="., $baa" />
				</xsl:variable>
				<built-in1>
					<xsl:value-of select="base-uri($built-in[1])" />
				</built-in1>
				<built-in2>
					<xsl:value-of select="base-uri($built-in[2])" />
				</built-in2>

				<xsl:variable as="element(*)*" name="traditional">
					<xsl:apply-templates mode="traditional-identity" select="., $baa" />
				</xsl:variable>
				<traditional1>
					<xsl:value-of select="base-uri($traditional[1])" />
				</traditional1>
				<traditional2>
					<xsl:value-of select="base-uri($traditional[2])" />
				</traditional2>
			</xsl:for-each>
		</test>
	</xsl:template>

I get the output:

<test>
   <original1>file:/Users/mike/bugs/2019/4097-hatanaka/test/test.xml</original1>
   <original2>file:/Users/mike/bugs/2019/4097-hatanaka/test/baa.xml</original2>
   <built-in1>file:/Users/mike/bugs/2019/4097-hatanaka/test/test.xml</built-in1>
   <built-in2>file:/Users/mike/bugs/2019/4097-hatanaka/test/test.xml</built-in2>
   <traditional1>file:/Users/mike/bugs/2019/4097-hatanaka/test/test.xml</traditional1>
   <traditional2>file:/Users/mike/bugs/2019/4097-hatanaka/test/test.xml</traditional2>
</test>

We can fix this by setting systemId=null in SequenceWriter after an endDocument() or endElement() event that takes the nesting depth down to zero. Whether this breaks anything else is another question...

The change appears to cause no regression, so I will commit it, and add some new test cases.