Bug #3445

Getting raw sequence result from Xslt30Transformer.CallTemplate

Added by Jiri Dolejsi about 4 years ago. Updated about 4 years ago.

Start date:
Due date:
% Done:


Estimated time:
Legacy ID:
Applies to branch:
Fix Committed on Branch:
Fixed in Maintenance Release:


In C# I want to obtain sequence of numbers by calling template, but I receive xml node:

using System;
using System.IO;
using Saxon.Api;
using System.Collections;

namespace Saxon
    class Program
        static string xslt = @"
            <xsl:stylesheet xmlns:xsl='' xmlns:xs='' version='3.0'>
                <xsl:template name='xsl:initial-template' as='xs:integer+'>
                    <xsl:sequence select='(1 to 5)'/>

        static void Main(string[] args)
            Processor processor = new Processor(true);
            XsltCompiler xsltCompiler = processor.NewXsltCompiler();
            xsltCompiler.XsltLanguageVersion = "3.0";
            XsltExecutable exec = xsltCompiler.Compile(new StringReader(xslt));
            Xslt30Transformer transf = exec.Load30();
            XdmValue res = transf.CallTemplate(null);
            int count = res.Count; // 1 - returns only one item
            XdmNode doc = (XdmNode)res.Simplify; // item is node
            IEnumerator it = doc.EnumerateAxis(XdmAxis.Child);
            string child = it.Current.ToString(); // 1 2 3 4 5
            string typeName = res.Simplify.GetType().Name;

I am using Saxon-PE


#1 Updated by Michael Kay about 4 years ago

  • Category set to .NET API
  • Status changed from New to In Progress
  • Assignee set to O'Neil Delpratt
  • Applies to branch 9.8 added

Thanks for reporting it. Without testing, I can see what's wrong: the .net API code is failing to call Controller.setBuildTree(false).

Unfortunately there doesn't seem to be an "escape-hatch" interface that gives you access to the underlying Controller.

Looking at the code I also noticed:

(a) the same problem applies to the "raw" applyTemplates() interface

(b) the interfaces that expect a tree to be constructed should explicitly call buildTree(true) in case a previous call has set it to false (this also applies on the Java side)

(c) the property name isAssertionsEnabled has been misspelled "ssAssertionsEnabled".

All suggests a need for a few more unit tests.

#2 Updated by Michael Kay about 4 years ago

Looking at point (b) on the Java side, I find that after calling callTemplate#1, a call on callTemplate(QName, Destination) works if the destination is a serializer (there is logic to set the value of buildTree conditionally depending on the output method). But it fails if the destination is an XdmDestination. It's bad form to have logic that tests whether the argument is an instance of a particular class: we should really have a method on Destination such as "isTreeDestination" which drives this.

But adding methods to an Interface is best avoided in a maintenance release, so for the moment, I have changed setBuildTreeConditionally() so that it explicitly sets buildTree(true) if the destination is not a serializer (for a serializer, it depends as now on the output method).

A fix for the Java-side problem has been committed, and unit tests added.

#3 Updated by Michael Kay about 4 years ago

  • Fix Committed on Branch 9.8 added

#4 Updated by O'Neil Delpratt about 4 years ago

  • % Done changed from 0 to 90

Replicated the fix made in the java code to the .NET code. Test the fix in the NUnit test cases.

#5 Updated by O'Neil Delpratt about 4 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 90 to 100

Added nunit test case.

#6 Updated by O'Neil Delpratt about 4 years ago

  • Status changed from Resolved to Closed
  • Fixed in Maintenance Release added

Bug fix applied in the Saxon maintenance release.

Please register to edit this issue

Also available in: Atom PDF