Firstly, it's important to remember that (conceptually at least) tree
construction is bottom up. You successfully create an an attribute typed as
attribute(*, xs:integer); then you create a <cell> element, and attach a copy
of the attribute to this element; then you create a <test> element, and attach
a copy of the <cell> element to this.
There is no validation attribute on the <cell> element, and no containing
element with a default-validation attribute, so the effect is as if you
specified validation="strip", which drops the type annotation on the attribute
when it is copied. To prevent this, I would suggest specifying
<xsl:variable name="test" default-validation="preserve"/>
which then also means you don't need the validation attribute on the <test>
element.
What you've got here is a sort of degenerate form of schema-aware processing in
which your schema only contains the built-in types. I haven't tried doing that
myself but it should work in theory.
Note also, (@row instance of xs:integer) is always going to be false: @row is
an attribute node, not an integer. What you want here is either (data(@row)
instance of xs:integer), or (@row instance of attribute(*, xs:integer)).
Michael Kay
Saxonica
On 26 Nov 2019, at 01:38, David Birnbaum djbpitt(_at_)gmail(_dot_)com
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> wrote:
Dear XSL-list,
I'm beginning to explore schema-aware processing, and for a real project I
need to create some temporary elements with attributes that I would like to
treat as integers. In the non-schema-aware version I explicitly pass the
attributes through the number() function when I need integer behavior, and
that does what I want, but I thought that if I typed the values as xs:integer
when creating them they would be recognized as instances of that type when
used, and would have integer behavior, so that I could avoid using the
number() function explicitly.
I created a small test sample below that replicates the problem I see in my
real code, and I would be grateful if someone could please advise about what
I've misunderstood. What I think I'm doing is creating a a variable that
contains <cell> elements with @row attributes that are typed as xs:integer,
and that therefore should behave as integers when I use them. But when I test
in the <xsl:for-each> at the end whether they are instances of integers, the
system reports that they are not. I'm running the tests at the command line
with Saxon EE and the -sa and -it switches. Thank you for any guidance you
might be able to provide.
Best,
David
__
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform
<http://www.w3.org/1999/XSL/Transform>"
xmlns:xs="http://www.w3.org/2001/XMLSchema
<http://www.w3.org/2001/XMLSchema>" exclude-result-prefixes="xs"
version="3.0">
<xsl:output method="xml" indent="yes"/>
<xsl:template name="xsl:initial-template">
<xsl:variable name="test" as="element(test)">
<test xsl:validation="preserve">
<xsl:for-each select="1 to 5">
<cell>
<xsl:attribute name="row" type="xs:integer"
select="."/>
<xsl:text>Hi!</xsl:text>
</cell>
</xsl:for-each>
</test>
</xsl:variable>
<xsl:for-each select="$test//cell">
<xsl:message select="@row, @row instance of xs:integer"/>
</xsl:for-each>
<root>
<xsl:sequence select="$test"/>
</root>
</xsl:template>
</xsl:stylesheet>
XSL-List info and archive <http://www.mulberrytech.com/xsl/xsl-list>
EasyUnsubscribe <http://lists.mulberrytech.com/unsub/xsl-list/293509> (by
email <>)
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--