RE: Apply-templates - how to omit top level element ta

Wendell Piez >> Accordingly, an "XML document" as seen through the lens
of XSLT/XPath has no "tags", and you won't hear us talking about tags.
(What you're more likely to hear is David C saying "don't talk about
tags".)

Remember that part about you saying "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...."  :) :) :)

Wendell Piez >> You have run into a difficulty that is social, not
technical. Lacking a complete description of the problem, several of us
have tried to help with various suggestions, some of which may actually
be more helpful than others. There is no one to be blamed for this:
after all, you need to be an expert in XSLT to know how to summarize and
present problems efficiently in XSLT-speak.

Sadly, I completely agree. :(

Wendell Piez >> Of course we can't warrant that all suggestions on the
list will be good ones. This is why successful XSLTers are skeptical and
do not just paste code without understanding it.

But I have to paste code to test it, otherwise I'll never understand it
(some people might, but I learn through trial and error)! :)


>> BTW, <xsl:apply-templates select="Name/node()"/> is just the same as
<xsl:apply-templates select="Name"/> if you also have a template...
>> <xsl:template match="Name">
>>    <xsl:apply-templates/>
>> </xsl:template>
>> ...which happens to be exactly what will happen to a "Name" element
(or any other template) by default (if you give no template). Thus,
>> select="Name/node()" is not the only solution or necessarily the best
one to your problem. (If you need a template matching Name
>> that does something else, then it might be.)
>>
Not so (I've just learned) when this is also part of the stylesheet:

	<xsl:template match="@*|node()">
		<xsl:copy>
			<xsl:apply-templates select="@*|node()"/>
		</xsl:copy>
	</xsl:template>

Of course I didn't realize that until I had to produce a cut down
version of the example to email you before.

>> I do hope that in your object-oriented code, despite having
encapsulated things, you still know "how it works throughout". That is,
you have a concept of how that code will be compiled and executed and
how its different parts will relate to one another.

Yes, but I don't have to worry about a global variable changing and
having a tested part of my encapsulated code no longer work.  I have
seen that happen many times when building my stylesheet, and can find
nothing that changes this.

BTW, I think my comments are stepping on the toes of the "XSLT
religion", for that I am sorry.  I am just a Secularist and try to apply
critical thinking whenever possible, but of course I'm human so I'm
still flawed.

>> There are such ways: they're called template rules. Because in XSLT
transformations the "entirely new context" is usually defined in
relation to the input document, the primary (though not the only)
mechanism for relating templates to their context of execution is the
match pattern.

I'm not familiar with XSLT "template rules"; is this a 2.0 concept?

Thanks again...

-Mike