Re: Re: [XSL] Implicit Predicate Casting

Because when the predicate is not of type "number", then the argument is cast to type "boolean". A non-empty string is cast to boolean true, so all members are exposed. A result tree fragment or temporary tree always casts to boolean true, so all members are exposed.

Only when the predicate is of type "number" is the "position()=" implied

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

So in my example, the value being the same for every node (nothing depends on the node in
the expression), is true for every node and selects everything!

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.
For maintenance, you have to track back the type of 'something' to understand the meaning
of the predicate which can then be very different.
Then, I would consider good practice, if what you want is a predicate [position()=something]
to make it explicit, unless you are pretty sure 'something' is really a number, such as in the
expression: [2], where 2 is obviously a number!..

And even for that... if you are a bit tired and wrote ['2'], being confused to where you have
to quote things or not... you will fall down to boolean-casting-and-selecting-everything.

So, if I ever run a class as you seem to do Ken,

I will advise to *always* make position()
explicit even for [position()=2], which would be good for sleepy students that wrote
[position()='2']

Because <xsl:value-of/> acts on only the first of the addressed nodes in document order. All three are being addressed, but only the first is being returned.

Ok! So that falls under differences between XSLT1.0 and 2.0

The XSL2.0 norm is much more accurate when such errors happens. It even gives an
error number which is very nice when you want to understand what's wrong, thanks to
the W3C guys that wrote this norm!

Chapter 17 of XSL1.0 (Conformance) says :
A conforming XSLT processor must signal any errors except for those that this document
specifically allows an XSLT processor not to signal. A conforming XSLT processor may
but need not recover from any errors that it signals.

So Firefox is wrong reporting nothing,

Human brain is complicated... I got it right for not(not(a=b) and not(a!=b)) meaning both sequence a and b are not empty,

but couldn't get a grip on that XPath implied thing,
which is a very basic thing !

The XPath norm is much more difficult to read, because it is constructed as a grammatical tree.

So, you've got to drill down very deeply to understand what's really happening.

--
Comprehensive in-depth XSLT2/XSL-FO1.1 classes: Austin TX,Jan-2008
World-wide corporate, govt. & user group XML, XSL and UBL training
RSS feeds:     publicly-available developer resources and training
G. Ken Holman                 mailto:gkholman@xxxxxxxxxxxxxxxxxxxx
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/s/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Cancer Awareness Jul'07  http://www.CraneSoftwrights.com/s/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal