[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

RE: [xsl] template match : node-set paring through multiple-axis relationships

---

---

> <xsl:variable name="focus" select="current()"/>
> 
> so focus is the current node.
> 
> 
>  test="current()[$b2]
> 
> $b2 is a node set so if used as a predicate it is true if and 
> only if it
> is non empty. It's a bit odd to use that in a path expression 
> as it is a
> constant predicate it doesn't depend on the nodes being filtered
> 
> [$focus]
> 
> the focus variable is always non empty as it is the current node, so
> this predicate is the same as [true()] and never does anything.
> 
> 
> [//
> 
> again it is very strange to start a predicate with // as it means that
> you are filtering a node set based on a filter that will have 
> a constant
> value over the set being filtered.
> 
> Sorry I can't suggest what you should have as I'm not sure what your
> transformation is trying to test.

Hey David,

Thanks for the response.

I am glad you said something about the variables.  If I set a variable value
through a select, and then test that variable, I had thought it would be the
same as substituting the node-set that the variable represents.  Is this the
case?

The basic idea of the filter is that I only want to transform a node if a
whole slew of context exists - else, I either want to check to see if it
exists in another context, or else copy it to the final document.

So, in establishing the context, I had hoped to put all of the context match
into the 'template match=' portion of the template, rather than select an
object for the template, only to realize later that it did not meet all the
criteria.  If I could put it all in the match, then I could just generate
matches (all of these are generated from UML diagrams) for the final
template, and not worry about one node that can exist in duplicate contexts
(and therefore having the same template match priority).

The "[//" match is strange, but I do not think too strange for the purpose.
The problem is that the associations (c's) do not necessarily exist in the
same hierarchy tree as the 'b', but do exist in the same tree as the root
object, so I'm forced to go all the way back.

If you have any other suggestions or comments, I would appreciate them.  I
confess it is a very difficult problem to explain (and - I think - to
solve), but it should (in theory) be easier to solve with functional
programming than procedural.  the only problem is my newbieness to xslt.  :)

Jonathan

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

---