So that would fall under XPath "shortcut" expressions and tricks!
Specification could be:
If type of predicate is number
| then imply position() = that number (which is a test and
thus gives a
true/false result)
| else cast expression to boolean
Not quite. You're getting the effective boolean value of the expression,
which is not quite the same as casting to a boolean. For example, given the
string "false", casting to boolean gives false(), but the EBV is true().
I find it a very "dangerous" shortcut if you do [something]
relying on the type of 'something'
to imply position()= if it is what you meant.
Yes, polymorphic operators always carry this kind of risk: it's the same as
Java which overloads "+" to mean addition and string concatenation. Are you
sure you know what ''+32 is?
By all means use [position()=x] or [number(x)] if you want to make yourself
clear. In 2.0, I think a better approach is to be rigorous about declaring
the types of variables and parameters, so that such mistakes will not occur.
I'm afriad people who write ['2'] just need to learn not to, as indeed do
people who write
<xsl:variable name="x">2</xsl:variable>
Michael Kay
http://www.saxonica.com/
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--