Maintenance: Planio will be observing a scheduled maintenance window this Sunday, November 10, 2024 from 20:00 UTC until 21:00 UTC to perform important network maintenance in our primary data center. Your Planio account will be unavailable for a few minutes during this maintenance window.
Bug #5038
closedGetting error XTTE0590 'Required cardinality of value of parameter $stylesheet-base-uri is exactly one; supplied value is empty' when calling fn:transform with stylesheet-node created from fn:parse-xml
100%
Description
Under Node.js, when running the code
const SaxonJS = require('saxon-js');
const xslt1Source = `<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
version="3.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
exclude-result-prefixes="#all">
<xsl:mode on-no-match="shallow-copy"/>
<xsl:template match="data">
<h1><xsl:value-of select="name" /></h1>
<div>Age: <xsl:value-of select="age" /></div>
</xsl:template>
</xsl:stylesheet>`;
const xmlSource = `<data>
<name>John</name>
<age>25</age>
</data>`;
const result = SaxonJS.XPath.evaluate(`
transform(
map {
'source-node' : parse-xml($xmlSource),
'stylesheet-node' : parse-xml($xsltSource)
}
)?output`,
[],
{ 'params' : { 'xmlSource' : xmlSource, 'xsltSource' : xslt1Source } }
);
console.log(result);
I get the error
message: 'Required cardinality of value of parameter $stylesheet-base-uri is exactly one; supplied value is empty',
name: 'XError',
code: 'XTTE0590',
xsltLineNr: '408',
xsltModule: 'XSLT-SEF-compiler.xsl'
https://www.w3.org/TR/xpath-functions/#func-transform says about stylesheet-base-uri
: "A string intended to be used as the static base URI of the principal stylesheet module. This value must be used if no other static base URI is available. If the supplied stylesheet already has a base URI (which will generally be the case if the stylesheet is supplied using stylesheet-node or stylesheet-location) then it is ·implementation-defined· whether this parameter has any effect.".
I think setting a value for stylesheet-base-uri
is not mandatory if a node is supplied as stylesheet-node
.
Using 'stylesheet-text' : $xsltSource
instead of 'stylesheet-node' : parse-xml($xsltSource)
works fine so in that case Saxon-JS somehow has a base URI for the stylesheet or takes a different path not caring about the base URI.
A similar XQuery code run with Saxon-Java works fine without setting up the stylesheet-base-uri
:
let $xml-source := ``[<data>
<name>John</name>
<age>25</age>
</data>]``,
$xslt-source := ``[<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
version="3.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
exclude-result-prefixes="#all">
<xsl:mode on-no-match="shallow-copy"/>
<xsl:template match="data">
<h1><xsl:value-of select="name" /></h1>
<div>Age: <xsl:value-of select="age" /></div>
</xsl:template>
</xsl:stylesheet>]``
return
transform(
map {
'source-node' : parse-xml($xml-source),
'stylesheet-node' : parse-xml($xslt-source)
}
)?output
so that seems to support my understanding that Saxon-JS has a bug here when raising the error about the stylesheet-base-uri
.
Updated by Debbie Lockett over 3 years ago
- Assignee set to Debbie Lockett
Thanks for raising this bug and supplying the sample (and apologies for the slow response).
Node.js test test/nodejs/iss5038_test.js added, based on Martin's sample. The test demonstrates the issue using stylesheet-node
, while using stylesheet-text
is OK.
Updated by Debbie Lockett about 3 years ago
The failure occurs inside fn:transform
while attempting to compile the supplied stylesheet. As the error message says, this is a problem with the $stylesheet-base-uri
parameter referenced inside the XSLT-SEF-compiler.xsl stylesheet. So the problem is actually an internal error in the way that we set up the compilation of the supplied stylesheet. I can understand the confusion, but the error is not saying that the user should be supplying the stylesheet-base-uri
option in the fn:transform
call.
In the implementation of fn:transform
, we aim to XX compile the supplied stylesheet by calling the compileXSLT_EE
method, which requires the stylesheet to be supplied as a stylesheetNode
.
I'm not sure whether the problem is that the XX compiler assumes the stylesheetNode
has a base URI, when this is not necessarily the case; or that the stylesheetNode
should have a base URI, but we have failed to set it.
When the stylesheet is supplied using the stylesheet-text
option, we form the stylesheetNode
using Platform['parseXmlFromString']
, and the _saxonBaseUri
of the stylesheetNode
is set to be the string "NoStylesheetBaseURI"
.
When the stylesheet is supplied using the stylesheet-node
option, the _saxonBaseUri
property of the stylesheetNode
is taken from the _saxonBaseUri
of the supplied stylesheet-node
.
But here we have a case that the _saxonBaseUri
property of the supplied stylesheet-node
is null: in parse-xml
, the _saxonBaseUri
of the resulting node is set to be E.staticBaseUri(expr, context))
, which returns null in this case.
It seems that for compileXSLT_EE
(the compilation of the stylesheet) to work correctly, the supplied stylesheetNode
must have non-null _saxonBaseUri
defined. And I guess that this is why we set the strange base URI for a stylesheet supplied using the stylesheet-text
option (I can't see any other special handling for "NoStylesheetBaseURI"). It looks like we could solve the bug by also defaulting the base URI to this string in the case that _saxonBaseUri
is null or undefined for a node supplied using the stylesheet-node
option.
Updated by Debbie Lockett about 3 years ago
- Status changed from New to Resolved
- Priority changed from Low to Normal
- Fix Committed on JS Branch 2 added
Fix committed in CoreFn.js#2551, in the code for fn:transform
: to ensure the base URI (_saxonBaseUri
) of the stylesheetNode
supplied to the XX compiler is not null.
Updated by Debbie Lockett about 3 years ago
- % Done changed from 0 to 100
- Fixed in JS Release set to Saxon-JS 2.3
Bug fix applied in the Saxon-JS 2.3 maintenance release.
Updated by Debbie Lockett about 3 years ago
- Status changed from Resolved to Closed
Please register to edit this issue
Also available in: Atom PDF Tracking page