[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

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

Subject: Re: Re: <xsl:element> and literal elements
From: "M. David Peterson" <m.david@xxxxxxxxxx>
Date: Sat, 27 May 2006 22:57:15 -0600
use literal
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>
wrote:

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:choose>
      <xsl:when test="name() = 'foo'">bar</xsl:when>
      <xsl:otherwise><xsl:value-of select="name()"/></xsl:otherwise>
    </xsl:choose>


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

</xsl:template>

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

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] :

http://www.oreillynet.com/xml/blog/2005/08/part_2_assets_atom_feeds_and_a.htm
l
[2] :

http://www.oreillynet.com/xml/blog/2005/09/part_3_assets_atom_feeds_and_a.htm
l

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
to
 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 />
  	</xsl:template>

resulted in this output:

&lt;html_blah /&gt;

while this:

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

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
stylesheets
  are slow because of lots of looping and recursion, rather than because
  I'm not using literal elements.

  Cheers,
  Martin








-- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.