This would not be a simple undertaking since TE exploits an extension mechanism in Saxon-B that changed in version 9.2. The open-source "Home" edition (HE) includes most of what was in Saxon-B, with the exception of Saxon extensions and extensibility features that now require paid licenses to use. A considerable amount of technical debt has accrued.

The Saxon-B 9.0 library currently used by teamengine v4 is now 7 years old (2008) and has been obsolete for many years. The current release of Saxon-HE is 9.6. Since Saxon 9.2 the "old way" of binding extension functions by mapping the namespace URI of the function name to a Java class is not available in Saxon-HE; it is this change that impedes the upgrade from 9.0. The new extension mechanism is referred to as integrated extension functions.

The immediate aim is to determine what exactly breaks and to assess what would need to be changed in order to use the extension facilities in Saxon-HE.

The latest Saxon-HE library is available in Maven Central:

<dependency>
    <groupId>net.sf.saxon</groupId>
    <artifactId>Saxon-HE</artifactId>
    <version>9.6.0-7</version>
</dependency>

There are 50 compilation errors reported when attempting to build the teamengine-core module. Most of these occur in the following four classes:

• com.occamlab.te.saxon.TEXSLFunctionCall (15)
• com.occamlab.te.saxon.TEJavaFunctionCall (13)
• com.occamlab.te.saxon.GetTypeFunctionCall (8)
• com.occamlab.te.saxon.TEFunctionCall (4)

Created new branch: upgrade/32-saxon-he

The stylesheets used to generate the executable scripts make use of capabilities that are not available in the Saxon-HE edition. For example, in generate_xsl.xsl (see the teamengine-resources module) several Saxon functions are used, all of which require Saxon-PE or Saxon-EE:

• saxon:assign (for stack operations)
• saxon:line-number
• saxon:evaluate
• saxon:get-pseudo-attribute

There are also several reflexive calls to Java methods (java.io.File, java.net.URI classes) that are not available under Saxon-HE; these can likely be replaced by integrated extension functions.

Some things to note:

• it should be possible to implement a simple stack (of file names) without using the saxon:assign statements.
• an xsl:evaluate instruction with similar functionality is available as a standard feature in XSLT 3.0.

I confirmed that a reflexive method call can be replaced with an integrated extension function that implements the Saxon APIs and is then registered with the processor. For example, file:new($path) can be replaced by an integrated function, tns:new-file($path), that returns an XdmExternalObject wrapping a java.io.File object. Here's the function definition using the "simple" interface.

I noticed that the Saxon Artifact has id org.opengis.cite.saxon:saxon9:9.0.0.8.
Why does the group id contain cite? Where is the source code located?
Maybe, it is exactly same artifact downloadable here? https://sourceforge.net/projects/saxon/files/Saxon-B/9.0.0.8/

I have added changes for upgrading Saxon to Saxon-HE. Please find the changes in #468 PR.