Thanks for another view Michael.
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
do
<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.
So rather than saying dear processor I want this function to
return an integer, its almost saying I hope it returns an integer.
I.e. its not a request for a cast, its .... just to keep the typing
system happy (for those that need one :-) I.e. it does little for
the end user.
<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.
Ok, I'm with this now.
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();
abc.setElement(n);
if setElement expects an Element; you have to write
abc.setElement((Element)n);
This kind of cast is written "treat as" in XPath/XQuery (because SQL
uses "cast" to mean something different).
A view on this could be that its rather anti-user?
'I want it to be an integer' is demoted to 'I'll treat it as an integer if
allowed under the rules'.
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.
Yes, Jeni made that clear.
Thanks Michael.
regards DaveP
-
DISCLAIMER:
NOTICE: The information contained in this email and any attachments is
confidential and may be privileged. If you are not the intended
recipient you should not use, disclose, distribute or copy any of the
content of it or of any attachment; you are requested to notify the
sender immediately of your receipt of the email and then to delete it
and any attachments from your system.
RNIB endeavours to ensure that emails and any attachments generated by
its staff are free from viruses or other contaminants. However, it
cannot accept any responsibility for any such which are transmitted.
We therefore recommend you scan all attachments.
Please note that the statements and views expressed in this email and
any attachments are those of the author and do not necessarily represent
those of RNIB.
RNIB Registered Charity Number: 226227
Website: http://www.rnib.org.uk
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list