<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: XSLT Tips for Cleaner Code and Better Performance</title>
	<atom:link href="http://www.onenaught.com/posts/23/xslt-tips-for-cleaner-code-and-better-performance/feed" rel="self" type="application/rss+xml" />
	<link>http://www.onenaught.com/posts/23/xslt-tips-for-cleaner-code-and-better-performance</link>
	<description>A blog on web standards, accessibility, css, javascript, xslt, and more</description>
	<pubDate>Fri, 29 Aug 2008 03:17:23 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.1</generator>
		<item>
		<title>By: Anup Shah</title>
		<link>http://www.onenaught.com/posts/23/xslt-tips-for-cleaner-code-and-better-performance#comment-8408</link>
		<dc:creator>Anup Shah</dc:creator>
		<pubDate>Sun, 10 Aug 2008 03:19:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.onenaught.com/posts/23/xslt-tips-for-cleaner-code-and-better-performance#comment-8408</guid>
		<description>@Azat: Thanks for your comment.

Re the select and boolean: yes, that is definitely shorter, though I tend to prefer the explicit ./  for some reason. I often find it helps others in the team understand the context aspect which seems to be a tricky bit to get going with, initially.

Re the href: I used to do this. Somewhere I read that this is slightly less performant, but I can't remember if it was just for the MSXML processor I was using at the time or as a general thing. (Though using a compiled XSLT Processor, which MSXML also supports, and caching such a processor should minimize that issue, I guess.)

Do you know if there is such a performance difference in any of the major processors today? Perhaps it is a minimal enough difference these days that it is worth using your suggestion in a good percentage of the cases, anyway.

You are certainly correct however, and I should have perhaps clarified those things in the post.

Will update and mention your suggestions when I get a moment.</description>
		<content:encoded><![CDATA[<p>@Azat: Thanks for your comment.</p>
<p>Re the select and boolean: yes, that is definitely shorter, though I tend to prefer the explicit ./  for some reason. I often find it helps others in the team understand the context aspect which seems to be a tricky bit to get going with, initially.</p>
<p>Re the href: I used to do this. Somewhere I read that this is slightly less performant, but I can&#8217;t remember if it was just for the MSXML processor I was using at the time or as a general thing. (Though using a compiled XSLT Processor, which MSXML also supports, and caching such a processor should minimize that issue, I guess.)</p>
<p>Do you know if there is such a performance difference in any of the major processors today? Perhaps it is a minimal enough difference these days that it is worth using your suggestion in a good percentage of the cases, anyway.</p>
<p>You are certainly correct however, and I should have perhaps clarified those things in the post.</p>
<p>Will update and mention your suggestions when I get a moment.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Azat Razetdinov</title>
		<link>http://www.onenaught.com/posts/23/xslt-tips-for-cleaner-code-and-better-performance#comment-8398</link>
		<dc:creator>Azat Razetdinov</dc:creator>
		<pubDate>Sat, 09 Aug 2008 23:31:37 +0000</pubDate>
		<guid isPermaLink="false">http://www.onenaught.com/posts/23/xslt-tips-for-cleaner-code-and-better-performance#comment-8398</guid>
		<description>Your code is still cluttered. The following lines are completely identical:

select="./Orders"
select="Orders"

href="{concat($domain, '/product/?', $someProductId)}"
href="{$domain}/product/?{$someProductId}"

select="boolean($new = 'true')"
select="$new = 'true'"</description>
		<content:encoded><![CDATA[<p>Your code is still cluttered. The following lines are completely identical:</p>
<p>select=&#8221;./Orders&#8221;<br />
select=&#8221;Orders&#8221;</p>
<p>href=&#8221;{concat($domain, &#8216;/product/?&#8217;, $someProductId)}&#8221;<br />
href=&#8221;{$domain}/product/?{$someProductId}&#8221;</p>
<p>select=&#8221;boolean($new = &#8216;true&#8217;)&#8221;<br />
select=&#8221;$new = &#8216;true&#8217;&#8221;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: XSLT Profilers — onenaught.com</title>
		<link>http://www.onenaught.com/posts/23/xslt-tips-for-cleaner-code-and-better-performance#comment-3072</link>
		<dc:creator>XSLT Profilers — onenaught.com</dc:creator>
		<pubDate>Sat, 16 Feb 2008 17:50:40 +0000</pubDate>
		<guid isPermaLink="false">http://www.onenaught.com/posts/23/xslt-tips-for-cleaner-code-and-better-performance#comment-3072</guid>
		<description>[...] have not used XSLT profilers extensively. Just once in a blue moon. Some of the XSLT performance tips I have written earlier seems to have served me well, thus far, but I think more regular use of [...]</description>
		<content:encoded><![CDATA[<p>[...] have not used XSLT profilers extensively. Just once in a blue moon. Some of the XSLT performance tips I have written earlier seems to have served me well, thus far, but I think more regular use of [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>
