Saxon

Note that Saxon 9.8 is also failing this test.

There's this horrible code in TinyBuilder#272

        if (!pipe.isLocationIsCodeLocation() && location.getSystemId() != null) {
            tt.setSystemId(nodeNr, location.getSystemId());
        } else if (currentDepth == 1) {
            tt.setSystemId(nodeNr, systemId);
        }

The intent here is to take the system ID of a new element node either from the Location passed with the startElement event, or from the systemId property of the TinyBuilder, depending on a property of the PipelineConfiguration. On this occasion we're taking the value from the Location parameter, which is the stylesheet base URI.

This is the only place that pipe.isLocationIsCodeLocation() is called. The underlying property is false by default, and is set to true on most node creation paths (e.g. ElementCreator.constructElement) - but not on push-mode paths such as ElementCreator.processLeavingTail().

The obvious thing is for ResultDocument to call pipe.setLocationIsCodeLocation(true) and this indeed causes the test to pass.

However, it's deeply flawed, because (as far as I can see) all ResultDocument threads are sharing the same PipelineConfiguration and therefore modifying its properties in situ is going to cause trouble.

In this particular scenario, the result document is being created using an XdmDestination, and the base URI of the destination has been set using XdmDestination.setBaseURI(). The builder is created using XdmDestination.getReceiver(), and this sets the base URI property on the builder. I feel that in this situation, the base URI on the builder should take precedence over anything in the Location property of the startDocument event.

When we're building in push mode, there seem to be essentially two cases to consider:

(a) building from events originating with an XML parser. In this case the system ID of a node comes from the location information, which can change from one node to another based on the system ID of external entities (or XInclude, though that's slightly different). The base URI of the node in this case is a function of the system ID and any xml:base attributes.

(b) building from instructions in a query or stylesheet. In this case the base URI of the root node comes from the static base URI of the relevant instruction in the query/stylesheet, and the base URIs of other nodes in the tree are the same as the root, subject to any xml:base attributes.

The "locationIsCodeLocation" flag in the pipeline configuration is intended to distinguish these two cases.

Because of multithreading, etc, it would seem safer to have this flag in the builder itself. Surely we always know when creating the builder which situation we are in?

I've tried creating this flag in the builder and setting it in appropriate places. 3 failures in the XSLT 3 test suite: base-uri-024, -037, -041.

With some tweaks to the places where we set the new flag, all tests now seem to be working. Need to run more of the unit tests, however.