Re: Creating nodes for the source versus the results t

Hi Ed,

> With that long-winded preamble, is utilizing this kind of
> "nodeset()" extentsion function type of approach likely to be
> consistent/compatible/portable moving forward into the next
> generation of XSL?

In XSLT 2.0 (like XSLT 1.1 as was), there won't be the concept of
'result tree fragments' so there won't be the requirement to convert
the result tree fragment to a node set explicitly (using a
processor-specific extension function). You'll just be able to do:

<xsl:stylesheet version="2.0"
                xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

<xsl:template match="/">
  <xsl:variable name="pass1">
    <xsl:apply-templates mode="pass1" />
  </xsl:variable>
  <xsl:apply-templates select="$pass1" mode="pass2" />
</xsl:template>

...

</xsl:stylesheet>

As you can see, that's fairly close to what you have with the
extension function, so it's not a major change.

In my opinion, the best way of maintaining as much processor
independence as possible is to put those templates that rely on the
processor-specific extension function in a separate stylesheet that
you then import or include into your own. At least that way you only
have to change things in one stylesheet, and the change usually
involves only changing the namespace declaration (swapping in a
different namespace URI to be associated with the prefix). Many
processors now support exsl:node-set(), so that's pretty close to a
"standard" extension function, but Xalan-C++ is a major exception (the
other being MSXML).

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list