Andreas,
Thanks for your thoughts/feedback.
I'm a little confused about your first post regarding the use of xsl:key - I'm
currently using that in the stylesheet I included - is there another/alternate
use that you're talking about?
As far as the 'parameterized' key and match terms - I was pretty sure it wasn't
do-able, but its good to get confirmation of that. I, too, had considered the
positional approach (though I hadn't gone as far as actually figuring that
syntax out - your example really drives home the wonder of XSL - every time
I've done something w/ XSL, its blown my socks off w/ all of the possibilities,
as well as the simplicity of implementing them!), but in the end, I decided
that having hard-named, but structurally-free 'utility' elements was the
lesser-evil (ie, over having a particular structural/positional approach.) I
purposely didn't reference the 'data' elements (such as NODE, SRCD, etc)
anywhere in the stylesheet, as the idea is to have a generic/universal
stylesheet that I apply to most any data (ie, a generic package that database
users can generically utilize to overcome the shorcomings of
this version of Oracle's XML capabilities - ie, that there's no inherent way
to convert a!
hierarchical relational resultset into a hierarchical XML nodeset) - so, the
user of the package will need to have 3 elements w/ specific names in each
'data' element, but as long as those utility elements exist somewhere in his
data node structure, he should be able to apply it to almost anything that
would result from calls to the inherent database functionality (ie, a connect
by query passed to sys_xmlgen and sys_xmlagg). Such are the trade-offs in an
framework/API-style approach to development. :-)
Overall, I think I tend to agree w/ you on the empty container element
(CHILDREN/) - its a bit clearer to have the empty element than to have a
missing element - besides, the XML produced from the XSL is expected to be
further processed by the user (again, this is just to give them the raw data
that they should be able to get out of the database, but cannot), so they could
remove the empty CHILDREN/ nodes, etc in case-specific processing of their own.
Thanks again for your input and feedback - its truly very much appreciated!!!
Jim