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.
--~------------------------------------------------------------------
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>
--~--