> -----Original Message-----
> From: Jim Stoll [mailto:jestoll@xxxxxxxxxx]
>
> Anyway, I'd like to know if/how I can do this in a smarter
> manner, if I've made any serious mis-steps or such, if this
> approach is likely to bring the machine to its knees for large
> datasets, etc. (this will be occurring on the database server).
>

Hi,

I notice you're not using xsl:key, which could reduce the stylesheet needed
to obtain the wanted output to:

<xsl:stylesheet ..>

<xsl:key name="nodes-by-parentrowid" match="NODE"
         use="PARENTROWID_" />

<xsl:template match="ROWSET">
  <xsl:apply-templates select="NODE[LEVEL_ = '1']" />
</xsl:template>

<xsl:template match="NODE">
  <xsl:copy>
    <xsl:copy-of select="*" />
    <CHILDREN>
      <xsl:apply-templates select="key('nodes-by-parentrowid'
                             ,ROWID_)" />
    </CHILDREN>
  </xsl:copy>
</xsl:template>

</xsl:stylesheet>

>  - the prevailing philosophy as regards whether to have an empty
> CHILDREN element (see below) if there are no children or not

Well, I personally prefer to have an empty element indicating the absence of
it, as opposed to not having a CHILDREN element at all...

>  - I've tried to make this as generic as possible, as I have
> opportunity to apply it to numerous situations, but have been
> unable to find a way to parameterize the ROWSET_, ROWID_ and
> PARENTROWID_ tag names (ie, to allow the user to set these to
> another value in their database query and pass parameters to the
> stylesheet naming their substituted values) - if anyone has any
> thoughts on this, I'd be very interested to hear them, as well.
> (It works as-is, and is an acceptable work-around, but I'd at
> least like to know if its possible.)
>

If you want to parametrize the element names, you can test for their value
in two ways:

a. the XPath predicate [name() = $parameter]:
unfortunately this does not work in match patterns...

<xsl:template match="*[name() = $parameter]"> is illegal because of
'$parameter'. Had this been a literal string, no problem.

b. the relative position of the node in question
examples: the LEVEL_ or ROWID_ nodes will always be the first and second
child nodes of a NODE, so you can get to them, whatever their names, through
the expressions 'NODE/*[1]' and 'NODE/*[2]'

other example: the PARENTROWID_ node will always be the third child node of
a NODE with LEVEL_ different than 1, so 'NODE[*[1] != '1']/*[3]'

will give you the PARENTROWID_ whatever its particular name (or that of the
LEVEL_ node) is.


Hope this helps!

Cheers,

Andreas