Ok this has gone way further than I ever wanted. I did get the answer to the 
problem so thanks alot on that Marrow. 

I guess though now my curiosity is getting the best of me and that I am a 
bit lost on this point so here goes.

Regarding Neils post.

I agree though you could do 

test1(test2())
or 
function test1() {
  return test1 = test2()
}
which would be the same thing the confusion is that this is acceptable
[position()=last()-1] 
which I read as assigning an argument from a function to another function 
similar to example one above. matter of how an argument/parameter is assigned 
in a given language. Anyway.....

Marrow

I guess based on what you said I am confused if I am in the same nodal 
context why that doesn't work if 
[position()=last()-1] works
or
[postion()=4] works
or the solution you gave works
variable prev-position=postion()-1
[postion()=$prev-position]

I think that if I get you right (hopefully) that what you are saying is that 
inside of the predicate I am outside the current context???? If that is so 
then why does last()-1 work is that because it retains current()? 

"Jason Burr" wrote:

> I think what he was trying to say is this (if I'm wrong I hope he will 
> correct me)
> 
> postion() can be assigned or it can be evaluated but it can't do both at the 
> same time. 
> 
> In other words 
> 
> 1. You can ask position() what it's value is
> 2. You can tell position() what it's value is
> 3. You can't ask it what it is and then tell it what it is at the same time.
> 
> By assigning a variable you are asking it first and then telling it later 
> what it should be. 
> 
> The reason this seemed a wee bit nonsensical to me is that generally when 
> programming you have the ability to assign a value from the same value. 
> Because generally the statement to the right of a value assignment is 
> evaluated prior to its assignment on the left.
> 
> so in programming generally this is a perfectly acceptable thing to do:
> x = x + 1
> or
> myObjectValue = myObjectValue - 1
> because its being read more like
> 
> n = (x + 1)
> x = n
> 
> whereas with the predicate statement it is being read literally as
> x = x + 1 
> which can never be evaluated 
> 
> I think that is is because it is opening position() to accept a value and 
> therefore it has no value when requested after being opened for input. I'm 
> sure this is somehow by design and a perfectly good reason for it exists. 
> (late bound early bound language?) 
> 
> 
> "johndoe@d..." wrote:
> 
> >     I have seen and used the <xsl:variable name="PrevPos" 
> > select="position() - 1" /> through trial and error, but I have not really 
> > understood why exactly this is. I read the explanation provided by Marrow 
> > but it seems to have gone over my head.
> > 
> > 
> > 
> > "Jason Burr" <JasonBurr@d...> wrote in message 
> > news:DD97D787-424F-4D74-B742-C69F5084D333@m......
> > > Marrow,
> > >
> > > Thanks simply assigning  variable worked (never tried that because of all
> > > the "no variable reassignment" griping)
> > >
> > > My thinking on the predicate was that the order of execution would be
> > >
> > > 1. evaluate value of the (current) position()-1
> > > 2. assign that value to position()
> > > 3. retrive the node given the assigned position
> > >
> > > I guess my thinking was that = doesn't evaluate the truth a statement such 
> > > as
> > >
> > > x = x + 1
> > >
> > > But rather
> > >
> > > (newvalue of x <--- (x - 1))
> > >
> > > Anyway good stuff to know thanks again.
> > >
> > > "Marrow" wrote:
> > >
> > >> Hi Jason,
> > >>
> > >> > Not trying to accomplish any thing was just messing around and thought
> > >> that
> > >> > it might be a good way to check for the last record in a group during a
> > >> loop.
> > >> > Since I can't reassign variables and position() tells me where in a 
> > >> > loop I
> > >> am
> > >> > and position() can also be used to specify a node to look up it seemed
> > >> (maybe
> > >> > foolishly) that this was an easy way to know if the current node and
> > >> previous
> > >> > node for a given value match.
> > >>
> > >> The position() function when used **outside** a predicate will give you 
> > >> the
> > >> position within the currently processed node-set (e.g. that selected by a
> > >> @select on <xsl:apply-templates> or <xsl:for-each>).  When the position()
> > >> function is used **within** a predicate then it ruturns the index of the
> > >> node within the nodes selected by the XPath expression to the left of the
> > >> predicate.
> > >>
> > >> Your problem remains...
> > >>
> > >> >   <xsl:when test="/foo/bar[position()=position()-1]/@attrib">
> > >>
> > >> read the bit inside the [] predicate! ;)
> > >>
> > >> How can "position()=position()-1" ever evaluate to true???  It can't... x
> > >> can never equal (x - 1)... complete impossibility!  ;)
> > >>
> > >> Maybe one of those position()'s is the position prior to the predicate? 
> > >> In
> > >> which case you would need to store one to a variable first, e.g something
> > >> like...
> > >>
> > >>  <xsl:for-each select="bar">
> > >>    <xsl:variable name="curr-posn" select="position()"/>
> > >>    <xsl:choose>
> > >>    <xsl:when test="/foo/bar[position()=$curr-posn -1]/@attrib">
> > >>       ...
> > >>
> > >> or even just calc the index, e.g.
> > >>
> > >>  <xsl:for-each select="bar">
> > >>    <xsl:variable name="prev-posn" select="position() - 1"/>
> > >>    <xsl:choose>
> > >>    <xsl:when test="/foo/bar[$prev-posn]/@attrib">
> > >>       ...
> > >>
> > >> Cheers
> > >> Marrow
> > >>
> > >> "Jason Burr" <JasonBurr@d...> wrote in message
> > >> news:C68421B0-71EE-4519-B453-EEB0735C5504@m......
> > >> > Hey Marrow,
> > >> >
> > >> > Not trying to accomplish any thing was just messing around and thought
> > >> that
> > >> > it might be a good way to check for the last record in a group during a
> > >> loop.
> > >> > Since I can't reassign variables and position() tells me where in a 
> > >> > loop I
> > >> am
> > >> > and position() can also be used to specify a node to look up it seemed
> > >> (maybe
> > >> > foolishly) that this was an easy way to know if the current node and
> > >> previous
> > >> > node for a given value match. I am aware of Muenchian (you may have 
> > >> > helped
> > >> me
> > >> > out with that).
> > >> >
> > >> > Anyway the context of that example would have been in
> > >> >
> > >> > <foo>
> > >> >   <bar attrib='test'>
> > >> >   <bar attrib='test'>
> > >> >   <bar attrib='test2'>
> > >> > </foo>
> > >> >
> > >> > <xsl:for-each select="bar">
> > >> >   <xsl:choose>
> > >> >   <xsl:when test="/foo/bar[position()=position()-1]/@attrib">
> > >> >    <xsl:value-of select="@attrib"/>
> > >> >   </xsl:when>
> > >> >   <xsl:otherwise>
> > >> >     <xsl:value-of select="@attrib"/> end of group
> > >> >   </xsl:otherwise>
> > >> >   </xsl:choose>
> > >> > </xsl:for-each>
> > >> >
> > >> > Result expected
> > >> >
> > >> > test
> > >> > test end of group
> > >> > test2
> > >> >
> > >> > Clearly I didn't mess with the keys or anything for grouping but this
> > >> would
> > >> > work if the xml was ordered or if using the Muenchian Technique. (that 
> > >> > is
> > >> if
> > >> > it evaluated like it does when using value-of)
> > >> >
> > >> > As far as it evaluating to nothing thats not completely true becuase if 
> > >> > I
> > >> > hard code in the value of the position
> > >> >
> > >> > <xsl:value-of select="/foo/bar[position()=3]/@attrib"/>
> > >> >
> > >> > The the result would be
> > >> >
> > >> > test2
> > >> >
> > >> > and if I do
> > >> >
> > >> > <xsl:value-of select="position()-1"/>
> > >> >
> > >> > I would get
> > >> >
> > >> > 0
> > >> > 1
> > >> > 2
> > >> >
> > >> > So my general question was why would that not evaluate to the value of 
> > >> > the
> > >> > node (which does exist) and return the value requested. Further if 
> > >> > there
> > >> is
> > >> > no way for this to work then is there another way to evaluate the same
> > >> thing
> > >> > (the previous node processed in a for-each)
> > >> >
> > >> > Thanks,
> > >> >
> > >> > Jason
> > >> >
> > >> >
> > >> >
> > >> > "Marrow" wrote:
> > >> >
> > >> > > Hi Jason,
> > >> > >
> > >> > > > But that this never returns a result
> > >> > > >
> > >> > > > <xsl:value-of select="/foo/bar[position()=position()-1]/@attrib"/>
> > >> > >
> > >> > > Of course it won't ever return anything...  the predicate [] 
> > >> > > expression
> > >> can
> > >> > > never evalaute to true.
> > >> > >
> > >> > > > What I want to do here is look at the last record in a loop to see 
> > >> > > > if
> > >> I am
> > >> > > > at the end of a grouping (begininig of the next actually)
> > >> > >
> > >> > > Based on what you have described so far (but not seeing more of the 
> > >> > > XSLT
> > >> and
> > >> > > XML) I'd say it'is unlikely that your current method of doing 
> > >> > > grouping
> > >> will
> > >> > > work.  There are a couple of ways of doing grouping in XSLT 1.0 - the
> > >> > > Muenchian Technique and preceding-sibling technique.  I'm sure if you
> > >> post
> > >> > > an example of what your are trying to do someone will be able to show
> > >> you
> > >> > > how to do these.
> > >> > >
> > >> > > Cheers
> > >> > > Marrow
> > >> > > http://www.marrowsoft.com - home of Xselerator (XSLT IDE and 
> > >> > > debugger)
> > >> > > http://www.topxml.com/Xselerator
> > >> > >
> > >> > >
> > >> > > "Jason Burr" <JasonBurr@d...> wrote in message
> > >> > > news:3CEE074F-AD95-4124-ADD2-8DB46106D9BA@m......
> > >> > > > Can someone explain why doing this writes a number one less than 
> > >> > > > the
> > >> > > current
> > >> > > > position.
> > >> > > >
> > >> > > > <xsl:value-of select="position()-1"/>
> > >> > > >
> > >> > > > Doing this will display a specific positions value
> > >> > > >
> > >> > > > <xsl:value-of select="/foo/bar[position()=3]/@attrib"/>
> > >> > > >
> > >> > > > But that this never returns a result
> > >> > > >
> > >> > > > <xsl:value-of select="/foo/bar[position()=position()-1]/@attrib"/>
> > >> > > >
> > >> > > > What I want to do here is look at the last record in a loop to see 
> > >> > > > if
> > >> I am
> > >> > > > at the end of a grouping (begininig of the next actually)
> > >> > > >
> > >> > >
> > >> > >
> > >> > >
> > >>
> > >>
> > >> 
> > 
> > 
> >