Given input of the form
<?xml version="1.0"?>
<config_datastore>
<feature name="a">
<config id="1">
<param id="x">x</param>
</config>
</feature>
<feature name="b">
<config id="1">
<param id="y">y</param>
</config>
</feature>
<feature name="c">
<config id="1">
<param id="z">z</param>
</config>
</feature>
<site>
<has_feature name="a"/>
<has_feature name="c"/>
</site>
</config_datastore>
I want to be able to select /config_datastore/site/* and perform selective
grouping (on feature @name) and merging (on the feature/config elements)
to return:
<config id="1">
<param id="x">x</param>
<param id="z">z</param>
</config>
Naturally the has_feature elements under site may contain different @name
values (i.e., it won't always be 'a' and 'c'). My immediate thought
was that I could use nested for-each loops and key lookups to resolve
the config elements I am interested in:
<?xml version="1.0" encoding="iso-8859-1"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:key name="feature" match="feature" use="@name"/>
<xsl:template match="/">
<xsl:variable name="tree_fragment">
<xsl:for-each select="/config_datastore/site/has_feature">
<xsl:for-each select="key('feature', @name)/config">
<xsl:copy-of select="."/>
</xsl:for-each>
</xsl:for-each>
</xsl:variable>
<!-- need to then merge $tree_fragment/config elements -->
<!-- perhaps using node-set conversion -->
</xsl:template>
</xsl:stylesheet>
This leaves me with a rather unhelpful tree-fragment of the form
<config id="1">
<param id="x">x</param>
</config>
<config id="1">
<param id="z">z</param>
</config>
In order to then merge the two config elements, I'd need ot pass
$tree_fragment through some non-XSLT-1.0 compliant function to get
a node-set which I could further manipulate.
Two questions:
a) Is it considered fine w/re to "programming form" to use
these node-set transformations, given that we will get
them in XSLT 2.0?
b) Is there another way, using pure XSLT 1.0 functionality,
to perform the selective group and merge? I have vague
inklings of recursive scans of /feature/config inside
the processing of has_feature, but that seems as ugly as
my recursive counter post a few days ago (i.e., perhaps
flexible and 1.0 compliant, but ugly and slow).
Any insights would be appreciated!
Thank you for your time,
Jim
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
James A. Robinson
jimr(_at_)highwire(_dot_)stanford(_dot_)edu
Stanford University HighWire Press http://highwire.stanford.edu/
650-723-7294 (W) 650-725-9335 (F)
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list