Re: key with restricting the scope of use attribute

Okay I think I see where the misunderstanding is coming in; I
posted some misleading XML. Sorry for the confusion.

Let me explaing what I am doing in the large. I am traversing
a very large tree doing a dependency sort (topological sort)
among a set of blocks. Some of the blocks are themselves hierarchical
so when I encounter one of these I have to topologically sort
the block as normal but also descend into the hierarchical block
and recurse the dependency sort algorithm. The purpose of the
dependency sort is to generate c-code from XML in the correct 
sequence so inputs to one block are previously calculated. The purpsoe
of descending into lower blocks is to expand subroutines or
function calls. Magically this works in the real XML, but apparently I
am having some trouble providing a simplified example to the list.
As you can imagine the XML instance is large and tangled - too 
large to post.

When I came up with the sample XML, I trimmed it down severely,
droppng out many levels of hierarchy and converting children
to attributes to economize on space. I think I did this in
a misleading fashion. Jeni's (and David's) observation that the 
generate-id():@x:y  key value can only ever match a single node 
is true for the XML I posted.

>   randomID1:1:1
> 
> *Only* this particular b element will have this key because
> generate-id() produces a unique ID for a node.  Thus each key value
> will only ever access one node.

However, the real XML effectively has elements ahead of <b> and
in between the pieces of information I made attributes of <b>, 
@x and @y. So conceptually the info represented the XML
might be something like this:

<a>
 <aa>
  <b>
   <foo><bar><x>1</x><y>1</y></bar><foo>
   <foo><baz><x>1</x><y>2</y></baz><foo>
   <foo><bit><x>1</x><y>1</y></bit><foo>
   <foo><bem><x>2</x><y>2</y></bem><foo>
  </b> 
 </aa>
</a>
<a>
 <aa>
  <b>
   <foo><bar><x>1</x><y>1</y></bar><foo>
  </b>
 </aa>
</a>

What I am trying to avoid is while I am visiting say the first
b, I don't want to concern myself with an out-of-context match
x:y='1:1" that might come from another instance of <b> (like
the second).

At this point, I think I should correct the sample XML before 
proceeding with this thread, but the xsl:key definition and call 
to key() need to be reworked so generate-id() is not operating
on the matched node. Perhaps I should have used generate-id(..)
instead. Let me see if I can surgically simplify the actual XML
I am working with and I will repost.

Thanks for you comments.

Regards,

Dan



__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/

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