RE: [xsl] Apply-templates - how to omit top level element tags?

Subject: RE: [xsl] Apply-templates - how to omit top level element tags?
From: "Mike Schinkel" <mikes@xxxxxxxxx>
Date: Thu, 8 Sep 2005 16:53:43 -0400
Wendell Piez >> though some might feel sometimes we have "religion"

	I definitely get that feeling from participating on this list!
:) :) :)

Wendell Piez >> An exercise I often recommend for beginners:

	Thanks for this, I will definitely run through it next chance I

Wendell Piez >> In fact I suspect that your problem is actually quite
straightforward, even that you've solved it (a later post suggested that
didn't it?), and moreover solved it by *simplifying* your code, which
further suggests to me that you're on the right track even if certain
things about the built-in processing model are still unclear.

	Yes I did. I was actually looking for a simply solution, but all
the suggestions were complex. See my complete example in another email
showing what I learned through trial and error.

	BTW, as an example of the "fragility" I find with XSL, it turns
out this:

		<xsl:template match="@*|node()">

	Which I needed for other things was what caused
<xsl:apply-templates> to output the <Name> tags. To me that's definitely
a side-effect (no need to continue the discussion of side-effects, I
just wanted to give you a tangible example of how intertwined and
non-encapsulated I'm finding XSLT.)

Wendell Piez >> or that even if they are suited to XSLT, you, as a
programmer, do not really have the time and labor to invest in mastering
this new paradigm and learning to write that graceful and powerful code.
(If you're going to end up writing Perl, then it's best done in Perl,

	This as an aside; I'm evolving to believe that having many
languages to handle many different things is not good. I think it better
to have few generic languages that are extended to support many
different problems.  The reason is it is hard to learn many different
languages, each with their own paradigms, and often to solve a business
problem people need to traverse many different paradigms, which becomes
too overwhelming. If forces us to be stuck with taking way to much time
to solve business problems, and we've got to get beyond that (especially
if programming in the first world don't want to loose their jobs to
programmers in the third world!)

	So to me, having Perl/Python/PHP/Java/C#/VB.NET as base
languages with extensions makes more sense that lots of little
languages.  That said, I think that the fact XSLT is limited in its
ability to completely solve certain transform problems without having to
incorporate a scripting language or Java or similar severly limits its
usefulnees and adoption (i.e. problems that require multiple transforms
with intermediate output become input) because a business person might
learn XSLT, but then when you throw requirement to code in
Perl/Python/PHP/Java/C#/VB.NET into the mix, it becomes a total

Wendell Piez >> Based on subsequent posts I think your problem may be
solved, and that further researches will make it clearer to you how and
why. Try the exercise outlined above; read Evan's chapter at plus anything
else you can find on the XSLT processing model.

	Will do, thanks again!

Wendell Piez >> Sometimes in these threads we end up talking theory so
much that we fail to define the actual problem at hand sufficiently well
to really solve it....

	I definitely agree. :)


Current Thread