Project

Profile

Help

Bug #2563

closed

NPE in export when inferred type involves an aliased namespace

Added by John Lumley about 8 years ago. Updated about 8 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Internals
Sprint/Milestone:
-
Start date:
2015-12-29
Due date:
% Done:

100%

Estimated time:
Legacy ID:
Applies to branch:
9.7
Fix Committed on Branch:
9.7
Fixed in Maintenance Release:
Platforms:

Description

In cases where the inferred type of a sequence constructor involves a namespace that is aliased, the export action throws a NPE when recording the type of the sequence. This is shown in the following:

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    xmlns:X="XSL" exclude-result-prefixes="xs" version="3.0">
    <xsl:namespace-alias stylesheet-prefix="X" result-prefix="xsl"/>
    <xsl:template name="main">
        <xsl:variable name="properties" as="item()*">
            <X:attribute/>
        </xsl:variable>
        <result>
            <xsl:sequence select="$properties"/>
        </result>
    </xsl:template>
</xsl:stylesheet>

where the NPE is thrown in trying to get a URI from the NamePool for the inferred type of @$properties@: '@element(X:attribute)@'.

Changing the namespace to one that is not aliased gives correct behaviour.

The FixedElement.elementName does not have a fingerprint under these alias conditions (i.e. it's -1, possibly masked), but it does have the correctly aliased qname (i.e. in this case @xsl:attribute@).

Actions #1

Updated by John Lumley about 8 years ago

Looking somewhat deeper, FixedElement.computeFixedElementType() does not seem to have any special handling if the fixed element does not have a truly fingerprinted name. In this case, with no validation, the item type is computed as a new CombinedNodeTest with a NameTest generated using this redundant -1 fingerprint value.

Changing fixedElement:333 to something like:

 NameTest nameTest;
 if(fp == -1) {
       nameTest= new NameTest(Type.ELEMENT, elementName, config.getNamePool());
 } else {
       nameTest= new NameTest(Type.ELEMENT, fp, config.getNamePool())
}
itemType = new CombinedNodeTest(
       nameTest,
       Token.INTERSECT,
       new ContentTypeTest(Type.ELEMENT, Untyped.getInstance(), config, false));

appears to sort the problem, but the implications elsewhere in the type system need to be considered.

Actions #2

Updated by John Lumley about 8 years ago

  • Status changed from New to Resolved

This bug manifested itself only in conditions without optimisation (@-opt:0@).

Correction suggested by MHK of @FixedElement.computeFixedElementType()@:line 248 being

int fp = elementName.allocateNameCode(config.getNamePool()) & NamePool.FP_MASK;
int fp = elementName.getFingerprint();

seems to correct the problem. (MHK has added XSLT3 test namespace-alias-0902 to check).

Patch committed to 9.7 branch

Actions #3

Updated by O'Neil Delpratt about 8 years ago

  • Fix Committed on Branch 9.7 added
Actions #4

Updated by O'Neil Delpratt about 8 years ago

  • % Done changed from 0 to 100
  • Fixed in Maintenance Release 9.7.0.2 added

Bug fix applied in the Saxon 9.7.0.2 maintenance release

Actions #5

Updated by O'Neil Delpratt about 8 years ago

  • Status changed from Resolved to Closed

Please register to edit this issue

Also available in: Atom PDF