[Home] [By Thread] [By Date] [Recent Entries]
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
|

Cart



