Nope, I didn't mean [1] is the default in general, like for for-each or
value-of. I mean that in whatever situation I've got myself stuck in
with keys, the output I'm getting is the same whether the [1] is
explicit or not. So if it's because concat() is dealing with string and
not nodesets as output...how do I get it to output the string I'm
looking for? Or can't I? That's the problem I have. But thanks for
pointing out what concat() is actually doing - I hadn't thought about
that at all.
It occurred to me this morning that (regardless of the concat function
issues) the key I have there is matching author / name. And it's only
going to select each matching node once. So if i want it to select one
particular author node more than once based on associated
information...it isn't going to happen unless I match that associated
information. In a previous attempt I used a key based on the topic, but
it ends up with the same problem if there's multiple authors. I can't
get it to select the same topic more than once based on multiple author
names. I hope this makes some sense. It seems like some kind of many to
many relationship problem. I want all unique combinations of topic and
author within a source's entry, though both can have multiple values. It
seems like a key may not be able to handle this, but I can't see what
else to do. And I'd also like to understand better why this is such a
problem. Is there a more theoretical reason, or more of the general
grouping problems in 1.0, or am I still just not understanding what I'm
trying to do?
Thanks,
Patrick
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--