Re: [xsl] Computed Location Predicate

[Jeni Tennison <jeni@xxxxxxxxxxxxxxxx>]

Hi Richard,

> I have a most vexing problem. I am writing a transform to create a
> sample document from a schema. For fun, I thought I would randomize the
> During the course of debugging, I used the the following without
> success:
>
>             <xsl:variable name="elementValue">
>                 <xsl:choose>
>                     <xsl:when test="xs:enumeration">
>                         <xsl:value-of
> select="xs:enumeration[number(string-length($allValues) mod
> count(xs:enumeration) + 1)]/@value"/>
[snip]
>
> I understand that my problems with (many) earlier versions were due to
> the processor's inability to distinguish the predicate as a number
> rather than a non-number and therefore a boolean. But why does the
> processor differentiate between casting a variable to a number, which
> works, and casting an expression to a number, which does not work?

When a path, such as "xs:enumeration" is evaluated, it's evaluated
relative to the context node. Within a predicate, the context node is
the node that you're filtering. In the above, then, you're selecting
enumerations and within the predicate counting the number of *child
enumerations* that each enumeration has. Since the enumerations don't
have child enumerations, it isn't working as you expect. When you were
counting enumerations within the variable, the context node was the
restriction, which did have child enumerations of course.

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list