item()*  zipTrees(node() tree1, node() tree2, item()* zipnodeFun(),
item()*  ziparcFun())

where we do not know in advance what exactly the functions
zipnodeFun(), and ziparcFun() will be doing.

One application is tree merging, another obvious one is tree
differencing, yet another could produce the results of any binary
operation (boolean, arithmetic, bit-wise, ...) on any pair of
corresponding nodes, ..., etc. the possibilities are unlimited.

A word of caution is that getting agreement on the semantics of (or
even explaining well) such a function can be very problematic -- as
the experience with the F & O function deep-equal() showed...

There's already a foldl-tree() function in FXSL -- whenever there's
time I could try to write a zipTrees() function.

--
Cheers,
Dimitre Novatchev
---------------------------------------
Truly great madness cannot be achieved without significant intelligence.

At 11:51 AM 6/22/2006, David wrote:
> > awesomely elegant solution works
>
>'course elegance, like beauty, is in the eye of the beholder. Walking
>over the tree(s) recursively carrying a bit of state with you might take
>some more lines of code, but is probably more efficient than working out
>/descendant::*[$n] each time.

Indeed, but code footprint does make a difference, and as soon as you
start passing parameters around, XSLT's syntax proves a significant
impediment to its appearing graceful -- its steps may be right, but
not light. Whether something can *be* graceful without *appearing* so
is something I leave for us to ponder ... though I acknowledge that
an algorithm may be nice even if its synactic expression is not.

Sort of like dancing in hiking boots. If everyone is doing it, we may
fail to notice. But that doesn't make it pretty.

Cheers,
Wendell