Thank you Wendell and also a big thanks to Martin, for helping me to understand
this.
As i had inherited this xslt from someone else, who was no longer at my
company, i wasn't really sure what he was trying to do, and when we added
sibling module_impacted elements, i wasn't sure if what we had would continue
to work.
I suspected that doing the grouping at the parent errata_section element was
the problem, as we were skipping elements. Some, but not all! (And as i changed
the code slightly, i would skip elements that i had previously gotten.) But
what i didn't know was if either Muenchian grouping, or grouping in XSLT 2.0,
would handle the situation that i was now facing. (This partly due to the fact
that all examples i had seen of either grouping method, never really matched my
situation.) I didn't know if the structure of our xml source could be parsed
with some XSLT magic or if i'd somehow have to code a search function to go
through all the elements. I hoped not, and that has proven to be true!
As for moving towards XSLT 2.0, i have been wanting to get there but feel i
first have to fully understand XSLT 1.0 first! But i'm getting there!
Thanks to everyone here for your time and patience!
Russ
On Thu, Mar 19, 2015 at 07:34:23PM +0000, Wendell Piez
wapiez(_at_)wendellpiez(_dot_)com wrote:
Russ,
Yeah -- the for-each pulls all the errata_section elements that happen
to be the first one of the entire set with the same value for
module_impacted -- except that since you've added module_impact
siblings, it will be those that are the first one of the set of all
errata_section with *any* of the same module_impacted values. The key
can work many-to-one, and it does. This means in principle a
module_impacted can be dropped (if it never appears outside parents
that are also bound to other modules mentioned earlier).
To use Muenchian grouping, write your key to the module_impacted
elements themselves (by their values), not their parents. Then
for-each select="//module_impacted[generate-id() =
generate-id(key('module_impact_mentions',string(.))[1])]">
to iterate over these values (or rather, over a set of node proxies for them).
Or ditch the Muenchian grouping and join the modern world - XSLT 2.0.
Cheers, Wendell
On Wed, Mar 18, 2015 at 12:45 PM, russurquhart1(_at_)verizon(_dot_)net
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> wrote:
Hi All,
I have a question about using Muenchian Method in a specific situation.
I have an xml source file like the following:
<errata_section id="i875"
errata_type="bug"><title>Title</title><description> <para> Following a warm
Reset </para></description><devices_impacted>
<device_name>VAZER</device_name></devices_impacted><module_impacted>Boot</module_impacted></errata_section>
The existing xsl, that i am supporting, but didn't write, uses the
following key:
<xsl:key name="module-index" match="errata_section" use="module_impacted"/>
And they have used the following Muenchian Method algorithm to go through
all the unique module_impacted elements.
<xsl:for-each
select="//errata_section[generate-id(.)=generate-id(key('module-index',
module_impacted)[1])]"> <xsl:sort select="module_impacted"/>
<!-- Determine module_impacted elements, for given device_name, and output
table. -->
</xsl:for-each>
Everything went fine until, over time, we have added additional
module_impacted siblings to the errata_section element like this:
<errata_section id="i876"
errata_type="bug"><title>Title</title><description> <para> Following a warm
Reset </para></description><devices_impacted>
<device_name>VAZER</device_name></devices_impacted><module_impacted>Boot</module_impacted><module_impacted>Power-On</module_impacted><module_impacted>DMA</module_impacted></errata_section>
Once this happened we started to see that not all module_impacted elements
were being found for the given device_name. My question is, is this
happening because the element we are doing the generate-id function on, in
some cases would have multiple siblings in a given errata_section element?
Most of the examples i have seen of using Muenchian Method are keying on a
unique elment value that doesn't have any similar named siblings.
I'm just trying to understand if this structure would work at all.
Thanks for any info you can provide and thank you Martin Honnen for your
help so far!
Russ
--
Wendell Piez | http://www.wendellpiez.com
XML | XSLT | electronic publishing
Eat Your Vegetables
_____oo_________o_o___ooooo____ooooooo_^
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--