Project

Profile

Help

Bug #5038

Getting 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

Added by Martin Honnen 2 months ago. Updated about 1 month ago.

Status:
Closed
Priority:
Normal
Category:
XX compiler
Sprint/Milestone:
-
Start date:
2021-07-15
Due date:
% Done:

100%

Estimated time:
Applies to JS Branch:
2
Fix Committed on JS Branch:
2
Fixed in JS Release:
SEF Generated with:
Company:
-
Contact person:
-
Additional contact persons:
-

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.

History

#1 Updated by Debbie Lockett 2 months 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.

#2 Updated by Debbie Lockett about 2 months 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.

#3 Updated by Debbie Lockett about 2 months 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.

#4 Updated by Debbie Lockett about 1 month 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.

#5 Updated by Debbie Lockett about 1 month ago

  • Status changed from Resolved to Closed

Please register to edit this issue

Also available in: Atom PDF Tracking page