[xsl] Re: [XSL] Implicit Predicate Casting

[Alain <alainb06@xxxxxxx>]

Wonderful Ken, it helps a lot!

> 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
> Because that's a compile-time error there is no way around it.  There 
> are runtime ways of avoiding version issues encountered during execution:
>
>         <xsl:if test="system-property('xsl:version')>=2">
>
>         </xsl:if>
>   
I tried to find a way around and could not. This time I was right then, 
as there is no way around.
I guess with XSL2.0 we could use some kind of conditional inclusion 
(xsl:use-when) for that, but
this construct was not yet in 1.0.
> > ... or maybe it's a bug of I.E. that should not complain with this
> > attribute "as" and just ignore it, as Firefox does... or is this
> > behaviour "implementation dependant" ?
> >
> > (Of course, when I tried on browsers, I changed version of XSL to 1.0)
> >     
>
> XSLT 1.0 Section 2.1:
>
>    "It is an error for an element from the XSLT namespace to have
>     attributes with expanded-names that have null namespace URIs
>     (i.e. attributes with unprefixed names) other than attributes
>     defined for the element in this document."
>   
Ok ;-)
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, but seems to recover from the 
unreported error,
whereas I.E. reports the error as it has to do according to the norm, 
but does not recover.
As it is not specified if this type of error is recoverable, I guess 
apart from not reporting,
both brothers behave correctly.

> I hope this helps.  These are actually common questions in the classroom.
>   
Yes indeed.
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.

Thanks Ken, and members of the list.