RE: [xsl] Advice/feedback on stylesheet?

Subject: RE: [xsl] Advice/feedback on stylesheet?
From: "Jim Stoll" <jestoll@xxxxxxxxxx>
Date: Mon, 29 Mar 2004 15:36:53 -0500
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

Current Thread