Re: [xsl] Re: <xsl:element> and literal elements

Subject: Re: [xsl] Re: <xsl:element> and literal elements
From: "M. David Peterson" <m.david@xxxxxxxxxx>
Date: Sat, 27 May 2006 22:57:15 -0600
Obviously I coded the example inline to this email:

you would probably want to add an </xsl:variable> but I would also not
encourage any of you to copy and paste the sample, as you can find MUCH
better ways to gain the same result for a use case in which this sample
would be useful (e.g.  For EVERYTHING that didn't match another
template/@match first.)

e.g. copy and copy-of would be a better choice in such cases.

On Sat, 27 May 2006 22:47:32 -0600, M. David Peterson <m.david@xxxxxxxxxx>

This all seems a matter of preference.  Which is fine.  But preferences
are different from rules obviously.

Setting aside personal preference, I use the same general rule that
Wendell alluded to earlier (I think in this same thread, but I read it a
day or two ago, so I'm not certain)

When you need to make a decision at run time as to what the output
element name and namespace (or simply name() for the
namespace:element-name, or local-name() for just the element-name if you
plan to copy the current element name into the output stream) will be,
use xsl:element.

For example (a VERY simply example -- not much use-case focus place on
this obviously)

<xsl:template match="*">

   <xsl:variable name="$output-name">
      <xsl:when test="name() = 'foo'">bar</xsl:when>
      <xsl:otherwise><xsl:value-of select="name()"/></xsl:otherwise>

<xsl:element name="{$output-name}"> <xsl:value-of select="."/> </xsl:element>


For a slightly more advanced way of using dyanmic element naming see:
([1],[2]), otherwise, the above should provide enough to at least think
about how to implement a dynamic naming system and when it seems like a
good idea to use one or the other in regards to Wendell's original

Performance and personal preference are the only other two reasons I can
think of to use one over the other.

Performance is processor dependent, but using a simple "calling an
instruction via an instruction element is going to invoke a process
beyond simple output serialization".

Personal preference is (GoTo: start of this sentence.) ;)

[1] :
[2] :

On Sat, 27 May 2006 11:29:24 -0600, Martin Holmes <mholmes@xxxxxxx> wrote:

Hi there,

  Wendell Piez wrote:
  At 06:31 PM 5/25/2006, you wrote:
 I'd be curious if people on this list
 have opinions on whether or not they've come up with rules for when
 use literal result elements and when to use xsl:element.
   My $0.02:
  Use literal result elements when you can; use xsl:element when you
have to.

Interesting -- my instincts are completely the opposite. I like the clarity of <xsl:element and <xsl:attribute. I like all actual elements in the stylesheet to be in the xsl namespace if possible. I don't like the idea of literal text containing angle brackets that turn into elements in the output data; it seems a little confusing. I think I would actually prefer it if this:

  	<xsl:template match="xml_blah">
  		<html_blah />

resulted in this output:

&lt;html_blah /&gt;

while this:

  	<xsl:template match="xml_blah">
  		<xsl:element name="html_blah" />

resulted in this:

<html_blah />

  I use <xsl:element and <xsl:attribute wherever I can, and I've never
  noticed any real impact on speed (although most of my slower
  are slow because of lots of looping and recursion, rather than because
  I'm not using literal elements.


-- Using Opera's revolutionary e-mail client:

Current Thread