Re: [xsl] Muenchian work if more than one value is present

Subject: Re: [xsl] Muenchian work if more than one value is present
From: "Wendell Piez wapiez@xxxxxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Fri, 20 Mar 2015 17:47:15 -0000
Russ,

XSLT 2.0 is just XSLT 1.0, except almost all the things that were hard
are now easy, and all the things that were impossible in practical
terms are now possible.

Seriously -- any good XSLT programmer needs to know about keys, and
how to tell when two nodes (with the same value for 'x') are actually
the same node. If you can do that (with nodes acquired using keys or
brute force), you can reinvent Muenchian grouping.

But if you have XSLT 2.0, you have native grouping, and that makes it
unnecessary to use keys and element proxies to solve this kind of
problem.

(If you don't know the actual requirements your code addresses -- why
it is doing what it is doing -- you have a different problem. :-)

Using XSLT 2.0 grouping, you can put your errata_section elements in
groups by their module_impacted values, and any errata_section with
more than one different module_impacted will turn up in more than one
group.

Of course (it too is a Turing-complete language) you can also do this
in XSLT 1.0 - and even use Muenchian grouping to do it - but it's way
harder.

I think when you try 2.0 you'll discover it's pretty much what you
know, only better.

(Hey, come take the class at Mulberry! - May 11-13, Rockville MD
http://www.mulberrytech.com/services/classes/upcoming.html. )

Cheers, Wendell

On Fri, Mar 20, 2015 at 8:55 AM, Russell Urquhart
russurquhart1@xxxxxxxxxxx <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
wrote:
> 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@xxxxxxxxxxxxxxx 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@xxxxxxxxxxx
>> <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> 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</mod
ule_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</mod
ule_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_^
>>
>



--
Wendell Piez | http://www.wendellpiez.com
XML | XSLT | electronic publishing
Eat Your Vegetables
_____oo_________o_o___ooooo____ooooooo_^

Current Thread