xsl-list
[Top] [All Lists]

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

2005-09-08 12:18:02
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.

--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--



<Prev in Thread] Current Thread [Next in Thread>