[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
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?
Re: [xsl] xsl:key only checks first child, need to check all
|
Subject: Re: [xsl] xsl:key only checks first child, need to check all From: Patrick Warren <warr0120@xxxxxxx> Date: Fri, 28 Oct 2005 10:42:06 -0500 |
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
| Current Thread |
|---|
|
| <- Previous | Index | Next -> |
|---|---|---|
| [xsl] xsl:key only checks first chi, Patrick Warren | Thread | Re: [xsl] xsl:key only checks first, David Carlisle |
| Re: [xsl] unnecessary soap elements, David Carlisle | Date | Re: [xsl] xsl:key only checks first, David Carlisle |
| Month |