[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
At 09:33 AM 4/15/2003, you wrote:
You do have to take some care when applying medicine like this as a debugging technique: it's strong stuff, overriding the default processing of *any* element not otherwise matched by a template, so it'll suppress output also from higher in the tree if there are nodes there not matched with templates of their own.
Use with caution. Better: understand the underlying principles behind what Tom is doing --
1. There exist default templates that play a role even if you don't see them
2. These can be overridden with defaults of your own as a method of discerning, sometimes, what's really going on.
For example, it's sometimes helpful to use a diagnostic template like this (assuming non-standard HTML output is okay for testing purposes ;-) ...
which will litter the output with the names of nodes not matched by templates of their own (and therefore caught by this one). (With apologies for the <blink> -- you know what I mean.)
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
RE: [xsl] why doesn't 'self::NODE' work?
Subject: RE: [xsl] why doesn't 'self::NODE' work? From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx> Date: Tue, 15 Apr 2003 12:08:11 -0400 |
At 09:33 AM 4/15/2003, you wrote:
In addition to the other answers you have received, let me add a few things. First of all, your template is not returning the results you see. It may very well not even be called. Instead, your results are being returned by the xslt default template, which returns the text content of an element of there are no other templates available.
You can demonstrate this by adding a template that matches all elements but does nothing -
<xsl:template match='*'/>
Of course, I had to make an assumption about how you were trying to invoke your template, but when I added this null template, the output vanished.
You do have to take some care when applying medicine like this as a debugging technique: it's strong stuff, overriding the default processing of *any* element not otherwise matched by a template, so it'll suppress output also from higher in the tree if there are nodes there not matched with templates of their own.
Use with caution. Better: understand the underlying principles behind what Tom is doing --
1. There exist default templates that play a role even if you don't see them
2. These can be overridden with defaults of your own as a method of discerning, sometimes, what's really going on.
For example, it's sometimes helpful to use a diagnostic template like this (assuming non-standard HTML output is okay for testing purposes ;-) ...
<xsl:template match="*"> <blink> <xsl:value-of select="local-name()"/> </blink> <xsl:apply-templates/> </xsl:template>
which will litter the output with the names of nodes not matched by templates of their own (and therefore caught by this one). (With apologies for the <blink> -- you know what I mean.)
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 ======================================================================
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: [xsl] why doesn't 'self::NODE' , Passin, Tom | Thread | RE: [xsl] why doesn't 'self::NODE' , Wright, Steve |
[xsl] Deleting Duplicate Elements, Jan Zavoral | Date | Re: [xsl] Deleting Duplicate Elemen, Wendell Piez |
Month |