Possible Bug with typed variable in schema-aware XSLT

[fsteimke]

Hi,

we have a strange error in a complex schema-aware XSLT script. I tried to boil it down to a simple example. Environment is Windows 10 and <oXygen/> XML Editor 19.1, build 2017092911

We get an error message complaining about wrong types, which seems to be a bug. It occurs only when we use a typed variable. Everything is fine without the variable. Here is what we did: Define type tns:T as extension of xs:string by adding an id attribute, and a sequence of tns:t elements with type tns:T.

Code: Select all

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"

    targetNamespace="http://www.example.com" xmlns:tns="http://www.example.com">

    <xs:element name="r">

        <xs:complexType>

            <xs:sequence>

                <xs:element maxOccurs="unbounded" name="t" type="tns:T"/>

            </xs:sequence>

        </xs:complexType>

    </xs:element>

    <xs:complexType name="T">

        <xs:simpleContent>

            <xs:extension base="xs:string">

                <xs:attribute name="id" type="xs:ID"/>

            </xs:extension>

        </xs:simpleContent>

    </xs:complexType>

</xs:schema>

Write a XSLT script which transforms a sequence of elements with text content into a sequence of tns:t elements:

Code: Select all

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"

    xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:tns="http://www.example.com" version="3.0" exclude-result-prefixes="xs">



    <xsl:import-schema namespace="http://www.example.com" schema-location="extension.xsd"/>

    <xsl:output method="xml" indent="yes"/>



    <xsl:template match="input" as="schema-element(tns:r)">

        <tns:r xsl:validation="strict">

            <xsl:apply-templates select="*"/>

        </tns:r>

    </xsl:template>



    <xsl:template match="s" as="element(*, tns:T)">

        <tns:t xsl:type="tns:T">

            <xsl:attribute name="id" select="concat('t-', count(preceding-sibling::*) + 1)"/>

            <xsl:value-of select="."/>

        </tns:t>

    </xsl:template>



</xsl:stylesheet>

This script is fine, the result is valid with respect to the schema given. However, when i introduce a variable like this:

Code: Select all

<xsl:template match="input" as="schema-element(tns:r)">

        <xsl:variable name="tList" as="element(*, tns:T)">

            <xsl:apply-templates select="*"/>

        </xsl:variable>

        <tns:r xsl:validation="strict">

            <xsl:sequence select="$tList"/>

        </tns:r>

    </xsl:template>

i get a runtime error:

Code: Select all

Engine name: Saxon-EE 9.7.0.19

Severity: fatal

Description: XTTE0570: Required item type of value of variable $tList is element(*, Q{http://www.example.com}T); supplied value has item type (element(Q{http://www.example.com}t) intersect element(*, Q{http://www.w3.org/2001/XMLSchema}string))

Start location: 10:46

URL: http://www.w3.org/TR/xslt20/#err-XTTE0570

I will send the example to your support email. I think this is a bug.

Sincerely,
Frank

[fsteimke]

Further observation: when i switch from applied template to a named template, there is no runtime error anymore.

Code: Select all

<xsl:template name='t1' as="element(tns:t, tns:T)">

        <tns:t xsl:type="tns:T">

            <xsl:attribute name="id" select="concat('t-', count(preceding-sibling::*) + 1)"/>

            <xsl:value-of select="."/>

        </tns:t>

    </xsl:template>

When this template is called within $var (see my post yesterday), everything is fine. But the named template has exactly the same result type element(tns:t, tns:T) as the applied template, which causes a runtime error. Strange.

Sincerely,
Frank

[fsteimke]

Turned out to be a saxon bug. See https://saxonica.plan.io/issues/3628: When Saxon validates an element against a complex type with simple content (specified in this case using xsl:type on a literal result element), the resulting type annotation is the simple (content) type, not the complex type.

Has been solved in the trunk for Saxon 9.8, which will find its way into Oxygen.

Sincerely,
Frank Steimke