This approach also lets you write XSLT templates to do things like filter out code you don’t want, e.g. font tags, or more importantly script tags.

Hope that helps!

Good point. In XSLT 1.0 I can’t think of a way. I think you would have to use xsl:if under the element and then that means using xsl:attribute in that scenario.

I believe (though have not had any experience in it) that XSLT 2.0 has additional capabilities and syntax to allow that kind of thing.

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.

select=”./Orders”
select=”Orders”

href=”{concat($domain, ‘/product/?’, $someProductId)}”
href=”{$domain}/product/?{$someProductId}”

select=”boolean($new = ‘true’)”
select=”$new = ‘true’”