[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)
> > 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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|