Subject: RE: [xsl] Apply-templates - how to omit top level element tags?|
From: "Mike Schinkel" <mikes@xxxxxxxxx>
Date: Thu, 8 Sep 2005 15:18:02 -0400
Thanks for the reply. >> One is the use of the "element name" in different contexts. The more powerful way to deal with this is modes. If the structure is simple enough, you can just match further up the tree as Michael Kay just sent. Okay, I see that. The problem I had with it, when I want a generic match, is that I had do write a bunch of templates, which were very difficult to maintain if not really required. Put another way, in some cases I want "<Name>My Title<TradeMark/></Name>" to output "<h1>My Title(tm)</h1>" and in other cases "<h2>My Title(tm)</h2>", and still different in other cases. But I always wanted "My Title<TradeMark/>" to be converted to "My Title(tm)" and I never wanted output to look like this "<Name>My Title(tm)</Name>" All the suggestions here on the list were to create extra templates, which greatly increased complexity, but the simple answer I learned through experimentation was to tack "node()" onto "Name" ala "Name/node()" in the apply-templates select. In hindsight I'm surpised no one suggested that simple solution. >> Pulling relies heavily on value-of and for-each loops, building a document by grabbing nodes from the source xml document. It doesn't use apply-templates. It is tended to be used with more data-centric outputs where the input is pretty predictable. ... Push tends to rely on the processing model, using apply-templates. It is used primarily when working with "narrative" documents due to their unpredictable nature. Okay, then that's actually what I've evolved to, mostly, and it helps me understand how to think about architecting my docs. >> WIthout knowning more about the type of documents you are processing and how your other templates are dealing with the processing model it's hard to give advice on the snippets. My XML docs are the source for these: http://www.howtoselectguides.com/dotnet/obfuscators/ http://www.howtoselectguides.com/dotnet/pdf/ http://www.howtoselectguides.com/dotnet/visualstudio2005/ There's a lot of structure in them (i.e. products, vendors, scenarios, etc.) but then within each section there's a lot of narrative, which is where I want to use <TrademarkSymbol/> etc. to allow the author to embed references to templates like he would embed a macro. >> So use the default rules. Remember, your Name node in XPath can be seen as a tree, rep in crude ASCII form below... For me, I think one of the problems is the terminology used by the XSLT community. They refer to "node" which to me is an abstract concept, but rarely "element tags" and "element contents" which is more concrete. I'm learning, but find it frustratingly difficult. >> If you process the Name node and do "value-of", you're asking for the string representation of the Name node, So for example, the terminology you used when you said "the string representation of the Name node" would make me wonder "Do you mean '<Name>My Title<TradeMark/></Name>' or 'My Title'"? If you had said "the string representation of the Name node's element contents" it would be much clearer to me. >> If you do >> <xsl:template match="Name"> >> <xsl:value-of select="."/> >> <xsl:apply-templates /> >> </xsl:templates> >> You're going to get some funky output. This was suggested to me by someone else. It didn't work right. The solution I needed was simply: <xsl:apply-templates select="Name/node() /> >>I'm not sure how you are even causing "side-effects". It looks more like you have some other templates in your stylesheet but don't know what they are doing because you don't understand the processing model. Again, we are using the term "side-effects" in different ways. Let me use a different term: "fragility." I find a large XSL file to be very fragile, and it is relatively impossible to encapsulate logic. If you have a large push model XSL file, you have to understand how it works throughout, you cannot divide and conquer like I'm used to structured and object-oriented programming where, if I code well, I can write a subroutine that I can guarantee will work correct, or fail with appropriate diagnostics, no matter what is going on in the calling code. I don't see how to do that in push model XSL. For that reason, I find it very fragile, and frightening, actually. If there were ways to create encapsulation in XSLT, such as the ability to have stylesheets call portions of themselves recursively with entirely new contexts, then I think it might be possible for them to be much less fragile. >> You seem to be heading in the right direction, but it feels like you're playing around with too large of a stylesheet that you don't understand. You are correct, even though I wrote the entire thing (fyi it is currently 1440 lines long.) But my comments on inability to encapsulate are why (I think) I am having trouble as it seems to understand the stylesheet as I have to understand it in its entirety all at the same time! Thanks again. I'll slog through it... -Mike P.S. BTW, I solved the one problem why I started the thread.