Thank you again for your suggestions!

The combineNodes() method was enhanced and it now takes the context configuration (available in the extension function) as an argument (i.e. context.getConfiguration())
However, with that configuration or with a newly one (as it was initially), I have this behavior:

// we are inside the extension function, and we prepare to return the nodeInfo back to the XSLT transformation

// Note: just for debugging purposes, serializing (using QueryResult.serialize(nodeInfo)) the list of nodes (build from the XML fragments)
// which we intend to return to the transformation confirms that everything is fine!

// now call combineNodes(), to combine the list of nodes into one node:
bigNode = combineNodes( nodes, context.getConfiguration() )

// Note: for debugging purposes, serializing (using QueryResult.serialize(nodeInfo)) bigNode above does no longer work:
// The exception says: "java.lang.IllegalArgumentException: Unknown name code 1050066"

So it looks like the node names get mixed up from some reason, in both cases (i.e. with the context config or with a new one).
I also found this older post - - stating that using the same configuration is highly recommended.

Are there any further suggestions on what I'm doing wrong? .. or where I should be looking into?


On Sat, Dec 24, 2011 at 1:06 AM, Michael Kay <> wrote:
On 23/12/2011 20:56, Full Midnight wrote:
> Thank you for your advice!
> I should have probably said from the start that this is part of a
> framework; I am not trying to re-write XSLT, but in my case I really
> have to use these things to gain performance :-)
> I searched through the web quite a bit and found other hints about
> TinyBuilder, so I have started to play with it.
> So I have now something like this:
> public NodeInfo combineNodes(List<NodeInfo> nodes) throws Exception {
>         Builder docBuilder = new TinyBuilder();
>         Configuration config = new Configuration();
>         PipelineConfiguration pipelineConfiguration =
> config.makePipelineConfiguration();
>         docBuilder.setPipelineConfiguration(pipelineConfiguration);
>         docBuilder.startDocument(0);
>         for (NodeInfo nodeInfo : nodes) {
>             nodeInfo.copy(docBuilder, 0, 0);
>         }
>         docBuilder.endDocument();
>         docBuilder.close();
>         return docBuilder.getCurrentRoot();
> }
> .. and in the integrated extension function I use something like for
> returning the combined nodes to the transformation:
> return SingleNodeIterator.makeIterator( combineNodes( selectedNodes ) );
> Although no exception is thrown, I do not see any nodes being returned
> to the transformation (selectedNodes do contain valid XML nodes).
> Any suggestions on what I should be further looking into?
> Perhaps SingleNodeIterator is not what I should be using? Having more
> nodes to return.. perhaps NodeListIterator or ListIterator should be used?
> The ext. func. result type is NODE_SEQUENCE:
>    @Override
>     public SequenceType getResultType(SequenceType[] args) {
>         return SequenceType.NODE_SEQUENCE;
>     }
> Merry Christmas,
> M.
This all looks ok except that you should be using the existing
Configuration rather than creating a new one. However, I find it hard to
see why that should cause the effect you describe. What does
docBuilder.getCurrentRoot() return - does it look OK at that stage?

Michael Kay

Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity.
saxon-help mailing list archived at