RE: [xsl] Re: XSLT 2.0: On xsl:sequence and xsl:copy-of

Subject: RE: [xsl] Re: XSLT 2.0: On xsl:sequence and xsl:copy-of
From: "Michael Kay" <mhk@xxxxxxxxx>
Date: Mon, 13 Oct 2003 13:54:12 +0100
> > 
> > Yes, or at least partly. If you have an 'as' attribute on 
> > <xsl:variable> then it indicates the static type of the 
> variable, but 
> > the variable itself can be of a more specific type.
> > 
> Roughly (not using DC speak), the 'as' attribute is the one I 
> want, even if the contents (of xsl:variable in this example) 
> might vary?

"as" on xsl:variable is an assertion about the type. For example, if you

<xsl:variable name="x" as="xs:integer" select="my:prime-number()"/>

then you are asserting that the function my:prime-number() will return
an integer, or a value that can be (loosely-speaking) treated as an
integer. If it returns an xs:unsignedInteger, your assertion is correct,
because xs:unsignedInteger is a subtype of xs:integer. If it returns an
attribute node that contains an integer, or that contains an untyped
value that can be read as an integer, then you're also OK. But if the
function returns a string or a date, then you'll get an error. The
system can report this error at compile time if it can detect it then,
otherwise it will be a run-time error.

With a simpler case such as 

<xsl:variable name="x" as="xs:integer" select="'Bangkok'"/>

one would hope that most systems will report the error at compile time,
but the rules don't require this. (This is because we haven't tried to
define the concept of a "constant expression").

> > 
> > Similarly, if you have:
> > 
> >   <xsl:variable name="foo" as="xs:decimal" select="2" />
> > 
> > then the static type is a xs:decimal but the type of the variable's 
> > value is a xs:integer.
> ?? Dynamic is integer, static is decimal??
> Assuming such a cast is viable/allowed, any use of $foo
> will be as a decimal thereafter in the stylesheet?

You don't get casting here, only the weaker kind of conversion allowed
in function call and assignment contexts. This allows (a) extraction of
the content of a node, (b) numeric promotion (e.g. integer to decimal,
but not decimal to integer), and (c) casting of untyped values only.

The static type of $foo is xs:decimal, but the dynamic type of its value
is integer. Static types aren't likely to affect XSLT processors
significantly; they are much more important for some XQuery processors
(such as Microsoft's) which are proposing to implement "conservative"
static typing: which means the static type of an expression has to be
right for the context where it is used, not just the dynamic type of its
value. This might sound complicated but it's exactly what happens in
many programming languages like Java: it's an error to write

Node n = xyz.getElement();

if setElement expects an Element; you have to write


This kind of cast is written "treat as" in XPath/XQuery (because SQL
uses "cast" to mean something different).

> > 
> > As long as the dynamic type (the type of the value that the 
> variable 
> > gets set to) is a subset of the static type (the type of 
> the variable 
> > as declared by the 'as' attribute), you're OK.
> 'Can be cast to' I guess.

No: this is nothing to do with casting. You can cast a string to a date,
but you can't use a string in places where a date is expected. 

Michael Kay

 XSL-List info and archive:

Current Thread