|
RE: Apply-templates - how to omit top level element tags?
2005-09-08 13:11:00
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(_at_)mulberrytech(_dot_)com
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
======================================================================
--~------------------------------------------------------------------
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>
--~--
|
|