xsl-list
[Top] [All Lists]

Re: [xsl] [XSL] Implicit Predicate Casting

2007-10-13 10:33:58
At 2007-10-13 15:49 +0200, Alain wrote:
But there is still something that puzzles me a lot, and I still don't find the part that specifies the behaviour described below.

Let's consider :

XML input :
===========================
<?xml version="1.0" encoding="UTF-8"?>
<test>
   <element>first</element>
   <element>second</element>
   <element>third</element>
 <empty/>
</test>

===========================


XSL file :
===========================
...
   <xsl:variable name="pos">2</xsl:variable>
       <p>(2) element[$pos]=<xsl:value-of select="element[$pos]"/></p>
       <p>(3) element['2']=<xsl:value-of select="element['2']"/></p>
...
Ouput is (using Saxon 8.9)
===========================
...
(2) element[$pos]=first second third

(3) element['2']=first second third
...
On (2) and (3), the predicate expression (inside []) is a string (3) or
a variable (2) containing a string (or is it considered as a nodeset
containing a single text node under the root element of the variable ?).
It's obviously not trying to cast to a number because that gives a
different result as (4) where I cast it to a number.
...
*So my question is* : what is happening in (2) and (3) at XPath level to
get this result ?

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.

And also, why is the result different if the version of XSL is set 1.0.
It would then give only
      <p>(2) element[$pos]=first</p>
      <p>(3) element['2']=first</p>

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.

And by the way, I'm very newbie with xsl:fallback and stuff like that,
is there a way I can run this stylesheet with Internet Explorer without
having to comment out the last two  lines of the template, because I.E.
complains about the attribute "as" of  xsl:variable which, indeed, does
not exist in 1.0 ?
(so that's the third question !)

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>

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

I hope this helps.  These are actually common questions in the classroom.

. . . . . . . . . . . . . . Ken


--
Upcoming hands-on XSLT 2/XSL-FO 1.1 training:  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>
--~--

<Prev in Thread] Current Thread [Next in Thread>