This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: key with restricting the scope of use attribute
- To: xsl-list at lists dot mulberrytech dot com
- Subject: Re: [xsl] key with restricting the scope of use attribute
- From: Dan Diebolt <dandiebolt at yahoo dot com>
- Date: Fri, 11 May 2001 09:12:46 -0700 (PDT)
- Cc: Jeni Tennison <mail at jenitennison dot com>
- Reply-To: xsl-list at lists dot mulberrytech dot com
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