[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Apply-templates - how to omit top level element ta
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 get. 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()"> <xsl:copy> <xsl:apply-templates select="@*|node()"/> </xsl:copy> </xsl:template> 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, etc.) <soapbox> 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 non-starter. </soapbox> 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 http://www.oreilly.com/catalog/xsltpr/chapter/ch03.pdf 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. :) -Mike
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|