By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,290 Members | 1,631 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,290 IT Pros & Developers. It's quick & easy.

Comparing Subtrees in XSLT

P: n/a
Hey XML gurus,

Is there a way to write a template so that it will compare two XML
subtrees wholesale? I can't quite get my head around this problem.

Let's say I have these two XML trees, both have the same structure,
but one of them has a few different pieces of text than the other.

So my basic thoughts here are to first create a key that in essence
makes a catalog of all the elements in one of the subtrees, call it
tree A, with the key being simply the name of the nodes. Then I call
a template on the root node of tree B, and basically, for each node, I
generate the key so I can pull up the matching node in tree A and
compare them somehow.

By compare though, for each node in tree A I actually want to compare
all of it's children with all of the children in tree B so that if
they're all equal, I can ignore them. If a node in A has some child
that doesn't match it's equivalent child in B, then I need to write
that node. Otherwise, I ignore it and it is not in my XSLT output.

Does this make sense? Am I thinking about this problem the wrong
way? Any kind of discussion or pointing me in the right direction
would really help.

Jul 20 '07 #1
Share this Question
Share on Google+
2 Replies

P: n/a
Ryan Nordman wrote:
Is there a way to write a template so that it will compare two XML
subtrees wholesale? I can't quite get my head around this problem.
XSLT/XPath 2.0 has a function deep-equal:


Martin Honnen
Jul 21 '07 #2

P: n/a
Ryan Nordman wrote:
Thanks for your input. I took your advice and just used java along
with dom4j's API to get the job done.
Personally I have never understood the appeal of DOM4J. It's a bit more
Java-flavored, perhaps, maybe... but that appears to be its sole real
advantage; all the other things claimed for it have been supported with
fairly bogus examples.

Yes, as one of the authors of the W3C DOM spec, I'm biased... but I
would still recommend sticking with the DOM rather than DOM4J unless
there is something in the latter which is really a make-or-break for
you, simply because the DOM is a far more portable solution.

And if you have to use something like DOM4J, I'd recommend looking at
one of the competing systems derived from it. DOM4J's biggest weak point
is that it's concrete classes rather than interfaces, which leaves no
room to plug in a version which is more efficient for your particular
needs without completely ripping it out and replacing it. That may not
matter on toy applications; it definitely matters in the real world.

() ASCII Ribbon Campaign | Joe Kesselman
/\ Stamp out HTML e-mail! | System architexture and kinetic poetry
Jul 24 '07 #3

This discussion thread is closed

Replies have been disabled for this discussion.