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

Subject: RE: [xsl] Apply-templates - how to omit top level element tags?
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>
Date: Thu, 08 Sep 2005 16:11:00 -0400
Mike,

Another thing that may help you is to understand that the-XML-processed-by-an-XSLT-engine is not XML.

By which I mean it's not tags-and-text: rather, it's an in-memory structure with certain definable features that has been *derived* from an XML source document. (That's the job of an XML parser that processes the document before the XSLT engine can begin its work. There are, it is true, people who claim that this in-memory structure is the "true" XML and that the tags-and-text is merely a "textual representation" of the thing itself. But I'm not one of those people -- I'll ask "is my DOM the same as yours?" Fortunately the representation-of-XML-as-tree that we use in XSLT is well understood, stable, and consistent across implementations, so we can work happily despite the metaphysical debates.)

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".)

What it has is elements, attributes, text nodes, comments, processing instructions, and a "root", arranged in a hierarchy, a "tree", in which they are related as parents, children, siblings, descendants, ancestors etc. etc. All these kinds of things are "nodes" so you'll hear us talk about nodes quite a lot.

Within this context, "element" and "node" are not abstractions at all: they're concrete things we can grab and manipulate. But we can't grab and manipulate the tags: they have been parsed away, and will not be seen again until the tree is serialized (written out) again in XML syntax. If this ever happens, which it may not (since we could also pass this tree directly to another process, if we want, skipping the writing and parsing of XML).

At 03:18 PM 9/8/2005, you wrote:
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.

Some of us are still not convinced that there isn't anything yet simpler and more elegant for your case.


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.

>> 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() />

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. (Accordingly, we are grateful that you have quizzed us, since all the issues raised are things that many newcomers need to hear about.)


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.)

Which brings us back to 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.

Well designed stylesheets are both very robust, and have very nicely encapsulated 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 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.


Similarly, you need an accurate concept for how XSLT is compiled and executed and how its different parts (templates) relate to one another (and even more critically for XSLT, relate to the range of inputs for which they are designed).

This concept or model won't be the same as your the OO implementation you have installed in wetware. But once you have it, you'll find you'll be able to compose reliable XSLT in the same way as you can compose reliable OO methods.

At that point, XSLT is not so much scary as thrilling.

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.

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.


P.S. BTW, I solved the one problem why I started the thread.

That's good!


Cheers,
Wendell



======================================================================
Wendell Piez                            mailto:wapiez@xxxxxxxxxxxxxxxx
Mulberry Technologies, Inc.                http://www.mulberrytech.com
17 West Jefferson Street                    Direct Phone: 301/315-9635
Suite 207                                          Phone: 301/315-9631
Rockville, MD  20850                                 Fax: 301/315-8285
----------------------------------------------------------------------
  Mulberry Technologies: A Consultancy Specializing in SGML and XML
======================================================================

Current Thread