RE: [xsl] sorting question

Subject: RE: [xsl] sorting question
From: "Lars Huttar" <lars_huttar@xxxxxxx>
Date: Wed, 28 May 2003 12:15:04 -0500
margarit nickolov wrote:
> lars_huttar@xxxxxxx said:
> >   select="/*/sd:Service[sd:ServiceDescription/@ServiceName='Y'
> > 	and ../sd:Service[sd:ServiceID &lt; current()/sd:ServiceID]]"
>
> it works.

Are you sure?  I am surprised.  Looking at the definition of current()
in Kay's reference, I couldn't tell for sure what the value of
current() would be in this case: would it be the sd:Service
node currently being tested for inclusion in the select nodeset?
Or would it be whatever was the current node outside the statement
using the select?

Clearly, if we were doing a for-each or apply-templates, then inside
the body of the for-each or inside the applied template, current()
would evaluate to the current sd:Service node being processed.
But within the select statement, it was not clear to me.

Looking at the XSLT 1.0 spec, it seems that current() does *not*
take on the value of the node being tested, while the select
expression is being evaluated:

<blockquote>
  However, within square brackets the current node is usually different from the context node. For
example,

  <xsl:apply-templates select="//glossary/item[@name=current()/@ref]"/>
  will process all item elements that have a glossary parent element and that have a name attribute
with value equal to the value of the current node's ref attribute. This is different from

  <xsl:apply-templates select="//glossary/item[@name=./@ref]"/>
  which means the same as

  <xsl:apply-templates select="//glossary/item[@name=@ref]"/>

</blockquote>

In other words, current() is not the same as the //glossary/item
currently under evaluation.  So in our case, current() should
not be the same as the /*/sd:Service currently under evaluation.

Maybe it worked for you with certain data,
depending on how you used it in a stylesheet (i.e. depending
on what the current() node happened to be).
But I can't see how.  I'd be curious to see your stylesheet.
When I tried it a couple of different ways in a stylesheet,
it didn't work (i.e. it did what I thought it would, not what
you asked for).

> > But even if this worked, I don't think this would really be
> a win because it
> > could be much less efficient (order N*N) than your original
> approach (order N
> > * log N for sorting).
>
> I do not pursue any performance, just learning XSLT.

OK, fair enough. :-)

Lars


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


Current Thread