RE: XPath's role (Was: Re: [xsl] Re: . in for)

["Michael Kay" <michael.h.kay@xxxxxxxxxxxx>]

> > Basically, there is no way in XSLT of constructing a sequence. The
> > only thing you can construct using XSLT instructions are trees.
> > Given the addition of sequences to the data model, we needed to
> > provide some way of constructing a sequence. Doing it in XPath,
> > rather than by adding new XSLT instructions, (a) gives us a greater
> > level of commonality with XQuery, and (b) gives better
> > composability.
>
> I disagree with the statement that there is no way of constructing a
> sequence in XSLT, assuming that you were talking about XSLT 2.0 plus
> XPath 1.0. XSLT 2.0 gives us xsl:function, and xsl:function enables us
> to construct sequences because it allows us to return things other
> than trees.

But it can only return something that you can express as an XPath
expression, so that doesn't really help you.
>
> The other thing that I think makes sequence generation possible
> (though not particularly efficient) for simple typed values is the
> presence of the type attribute on xsl:variable. Assuming that:
>
>   <xsl:variable name="numbers"
>                 select="'1 2 3'"
>                 type="xs:integer+" />

Hmm. Potentially yes. But it doesn't really solve the problem of creating a
variable containing a sequence of nodes that is the result of a join.
> >
> > How else would you do:
> >
> > <xsl:variable name="emps"
> >   select="//employee[some $d in $departments
> >                      satisfies lower-case(./@dept) = $d]"/>
> > <xsl:if test="count($emps) > 10">
> >   <xsl:for-each-group select="$emps" group-by="@location">
> >     ...
> > etc.
>
> I think you meant:
>
>   <xsl:variable name="emps"
>     select="//employee[some $d in $departments
>                        satisfies @dept = lower-case($d)]"/>
>
> Otherwise I think the existential semantics of = are sufficient?

Yes, OK.
>
> This example could be handled with a mapping operator:
>
>   <xsl:variable name="emps"
>     select="//employee[@dept = ($departments -> lower-case(.))]" />

Yes, I agree that many cases can be handled with a mapping operator (i.e.,
without range variables). But it can't handle all cases. As I think I
indicated, I'm quite sure that we need the basic capability to map sequences
in XPath 2.0; I've got an open mind about the need to go the whole way with
range variables. (At one time I was advocating that we shouldn't). But my
instinct after all the experience of hacking around limitations in XSLT 1.0
is to go this time for a solution that's provably complete; it's not
actually that much extra effort to implement. If it can be shown that
user-defined functions can handle all cases that would otherwise need range
variables, that would certainly be an interesting argument to use.
>
> In the more general case you could handle it with a function...

Mike Kay


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