Thank you Mike. I can see that this bug is already solved in the Saxon 9.8 trunk.
I will update the Oxygen Forum Entry.
Frank Steimke
Von: mike@saxonica.com [mailto:mike@saxonica.com]
Gesendet: Dienstag, 16. Januar 2018 23:36
An: mike@saxonica.com; f-steimke@berger-und-steimke.de; xml-dev@lists.xml.org
Cc: support@oxygenxml.com
Betreff: RE: [xml-dev] Schema aware XSLT runtime error - is it a bug?
This is followed up as a Saxon bug here:
https://saxonica.plan.io/issues/3628
Michael Kay
Saxonica
----- Original Message -----
From: mike@saxonica.com [mailto:mike@saxonica.com]
To: f-steimke@berger-und-steimke.de, xml-dev@lists.xml.org
Cc: support@oxygenxml.com
Sent: Tue, 16 Jan 2018 18:54:26 -0000
Subject: RE: [xml-dev] Schema aware XSLT runtime error - is it a bug?
Interesting.
Saxon is creating the <tns:t> element with a type annotation of xs:string (rather than tns:T). The code does this quite deliberately, but I cannot find anything in the specs to justify it. The spec that defines how type annotations are established is the XDM data model, ยง3.3.1.1, which in effect says that the type annotation is the same as the [type definition] in the PSVI; the XSD 1.1 spec says this is the same as the "governing type" used for validating the element, which is clearly tns:T.
Michael Kay
Saxonica
----- Original Message -----
From: Frank Steimke [mailto:f-steimke@berger-und-steimke.de]
To: xml-dev@lists.xml.org
Cc: support@oxygenxml.com
Sent: Tue, 16 Jan 2018 18:41:19 +0100
Subject: [xml-dev] Schema aware XSLT runtime error - is it a bug?
Dear list,
i have an schema aware XSLT script which leads to a runtime error: type
mismatch. I don't understand that error, and think it may be a bug, so I
wrote an entry in the Oxygen Forum (see
https://www.oxygenxml.com/forum/topic15402.html). The Oxygen staff has
tested with different versions of the Saxon-EE engine. All recent versions
of Saxon (9.5-9.8) report this incorrect type error. Now I am doubtful,
maybe I just don't understand what's going on. Please help.
We have defined a type tns:T as an extension of xs:string.
<xs:complexType name="T">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="id" type="xs:ID"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
We have an template which, when applied to some element, will return an
element of this type tns:T (at least, this is how I understand the @as
attribute of the template, as well as the @xsl:type attribute).
<xsl:template match="s" 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>
This template is applied to populate a variable which can hold a sequence of
elements of this type.
<xsl:variable name="var" as="element(tns:t, tns:T)*">
<xsl:apply-templates select="*"/>
</xsl:variable>
Applied to an element with text content leads to a runtime error: System ID:
C:\tmp\possible-bug-with-types-variable\possible-bug-with-types-variable\ext
ension-with-var.xsl
XTTE0570: Required item type of value of variable $var is
element(Q{http://www.example.com}t, 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))
I can't understand this error, since the template should return exactly the
required type. Further observation is, that an explicit call to a named
template with the same signature (that is, the same value for it's @as
attribute) works quite well.
What am I missing?
Sincerely,
Frank Steimke
_______________________________________________________________________
XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.
[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
