Saxon » SaxonJS

The documentation for the save() callback says

The value to be saved. The format of this value is controlled by the value of options.resultForm: the default is to convert the value to JavaScript following the rules in XDM to JavaScript Conversion.

But this doesn't appear to be the case. The save() method is called from Expr.js#1875 as [Atomic.XS.string.fromString(out)] (an array containing a single XdmString) or from Expr.js#1886 as builder.result() (generally an array of Nodes).

As far as I can see, we take account of resultForm only for setting the principalResult, not for setting secondary results.

For fn:transform(), we supply a save() function that writes the supplied value directly to the output resultDocuments map. For this case, using an XDM item is appropriate, because we're returning a result to XPath/XSLT code. For SaxonJS.transform(), however, returning a value that's convenient for Javascript use makes more sense. And when we're writing the serialized result to file store, it always wants to be a Javascript string.

As an immediate fix, I suggest that where the destination is "serialized", we should always pass the serialized value to the save() method as a Javascript string, and it's up to the save() method what to do with it.

In the case where destination="file", our save() method writes the string to a method such as fs.writeFileSync().

In the fn:transform case, our save() method wraps it as an XDMString and puts the result in the map returned to the fn:transform() caller.

In the case where the user wants the result added to the SaxonJS.transform() result map, our save() method converts it to the form defined by the resultForm option.