XSLT with XProc - parameter binding in the required type

Question

I'm trying to translate my batch file calling the Saxon (version 8.9) into a XProc pipeline (Calabash). This is my batch call:

java -jar saxon8.jar -o out.xml in.xml style.xsl +config=config-file.cfg

The parameter config is defined in the stylesheet in this way:

<xsl:param name="config" as="document-node()"/>

The XProc part looks like this:

<p:load name="configLoad">
    <p:with-option name="href" select="'config-file.cfg'"/>
</p:load>
<p:xslt name="config">
    <p:input port="source">
        <p:document href="in.xml"/>
    </p:input>
    <p:input port="parameters">
        <p:inline>
            <c:param name="config">
                <p:pipe port="result" step="configLoad"/>
            </c:param>
        </p:inline>
    </p:input>
    <p:input port="stylesheet">
        <p:document href="style.xsl"/>
    </p:input>
</p:xslt>

The error message is this:

Required item type of value of variable $config is document-node(); supplied value has item type xs:string

I know the <p:exec> step but i don't want to use it, because the config-file shall be generated by other XSLT tranformations later. It shall also be reused by other XProc steps.

Is there a possibility to call the XSLT stylesheet with the correct parameter type? Thanks for your help!

Answer 1

Looks like you are out of luck with the current XProc standard. It states that parameters are name/value pairs where the data type of the values must be string of untypedAtomic. Don't ask me why..

http://www.w3.org/TR/xproc/#parameters

If you won't be composing the contents of your configuration dynamically, but are merely passing around contents of fixed files, you could pass through just a path to the appropriate config file, and use fn:doc() to read it from within the XSLT files.

I'd recommend against writing config files on the fly. Execution order within XProc may not be as sequentially as you might expect..

Alternative would be to pass through each config setting as a separate parameter, but then each setting would still have to comply to the flat parameter value type..

HTH!