[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

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

Subject: RE: XPath's role (Was: Re: Re: . in for)
From: "Michael Kay" <michael.h.kay@xxxxxxxxxxxx>
Date: Mon, 7 Jan 2002 16:58:55 -0000
RE: XPath's role (Was: Re:  Re: . in for)
> > 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

Current Thread


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.