At 2007-10-14 12:56 +0200, Alain wrote:
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
Yes, the implied comparison operator makes the expression result a 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!
Yes.
I find it a very "dangerous" shortcut if you do [something] relying
on the type of 'something'
There are a few other examples in XPath.
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!..
Yes.
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.
The boolean casting happens on the end result of the expression ...
other casting is going on within the expression.
So, if I ever run a class as you seem to do Ken,
(Note I license my training material to other teachers around the
world http://www.CraneSoftwrights.com/training/licensed.htm if you
were interested in doing so yourself)
I will advise to *always* make position()
explicit even for [position()=2], which would be good for sleepy
students that wrote
[position()='2']
Yes that would work because of the casting that goes on *in* the
expression, not with the result of the expression: when the
comparison operator is between dissimilar data types (in this example
a number and a string), the string is converted to a number before
the comparison.
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
Yes
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!
It is *very* helpful.
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,
I agree. Not reporting reportable problems is not
helpful. Developers using software that "helps" them by forgiving
problems will then trip over their users problems after deployment.
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,
Sorry ... you lost me there. Are you referring to a comparison
returning false if either operand is the empty sequence? This
catches students using "a!=b" and getting false (and thinking that
means a and b are equal which they are not because of an empty
operand) instead of "not(a=b)" which when false means that they are
in fact equal.
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.
Instructors should remember the formal specifications are written for
implementers more so than for users, thus making an excellent market
for books and training material.
So, you've got to drill down very deeply to understand what's really
happening.
As is so often the case for specifications. Training material can
present the concepts differently to help students understand.
. . . . . . . . . . . . . Ken
--
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(_at_)CraneSoftwrights(_dot_)com
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
--~------------------------------------------------------------------
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>
--~--