Bug #6040
open
Invalid warning displayed when map:contains() is used
0%
Description
If I transform the following XML with the XSL I obtain an warning. I think that the warning that should not be presented because in the template I match the "element" from the "relevant" parent, and in the XML I have an "irrelevant" parent. Probably an evaluation is made in this case for optimization, but the warning should not be displayed.
I tested with Saxon 11.4
An error occurred matching pattern {element(Q{}element)[Q{http://www.w3.org/2005/xpath-functions/map}contains(exactly-one(($some-map) treat as map(*)), atomizeSingleton(attribute::attribute(Q{}relevant-attribute)))]}: An empty sequence is not allowed as the second argument of map:contains()
<root>
<irrelevant>
<element/>
</irrelevant>
</root>
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="3.0" xmlns:map="http://www.w3.org/2005/xpath-functions/map">
<xsl:param name="some-map" select="map {}"/>
<xsl:template match="/*/relevant/element[map:contains($some-map, @relevant-attribute)]">
</xsl:template>
</xsl:stylesheet>
Updated by Michael Kay 19 days ago
When we find an element, then to see if the pattern matches we have to test (a) that its parent is named relevant, and (b) that the predicate matches. There's nothing in the spec that says which of these tests should be done first, and we try to make a decision about which approach is likely to perform better.
(When I say there's nothing in the spec, that's not actually correct. The notes in 5.5.3 and 5.5.4 of the XSLT 3.0 explicitly say that bottom-up evaluation of patterns is allowed, and might result in spurious errors.)
There's been discussion about this in the QT4 working group, and the consensus is that the processor should behave as if the predicates are only evaluated when the base expression selects something (moreover, it should be "as if" multiple predicates are evaluated from left to right). The "as if" means we can continue to optimise order of execution if we wish, but we should not raise an error if the "unoptimised" execution path wouldn't raise an error.
We haven't yet implemented these changes in all cases, especially not for pattern matching.
Please register to edit this issue
.