Re: Beware the count method with Muenchian grouping (w

Francis Norton wrote:
> Daniel Bowen wrote:
> >
> > Just for an opposing view point on this, on one stylesheet that I use
> > Muenchian grouping, I have a filter on the key "match".  When I use the
> > "count" method, I have to use the filter again when selecting the nodes,
but
> > when I use the "generate-id" method, I don't have to use the filter
again.
> > In my case, the "generate-id" method is 2-3 times faster!
> >
> > Example:
> >
> >   <xsl:key
> >     name="key-texture"
> >     match="Texture[0=count(preceding-sibling::Texture[1])]"
> >     use="concat(@texture, ':', @u, ':', @v)" />
> >   <xsl:variable
> >     name="primary-textures"
> >     select="//Texture[generate-id(.) = generate-id(key('key-texture',
> > concat(@texture, ':', @u, ':', @v))[1])]" />
> >
> > is faster for me than:
> >
> >   <xsl:key
> >     name="key-texture"
> >     match="Texture[0=count(preceding-sibling::Texture[1])]"
> >     use="concat(@texture, ':', @u, ':', @v)" />
> >   <xsl:variable
> >     name="primary-textures"
> >
> >
select="//Texture[0=count(preceding-sibling::Texture[1])][count(.|key('key-t
> > exture', concat(@texture, ':', @u, ':', @v))[1])]" />
> >
>
> Did you try
>
> <xsl:variable
>   name="primary-textures"
>   select="//Texture[count(. | (key('key-texture', concat(@texture, ':',
> @u, ':', @v))[1]) = 1]"
>   />
>
> which seems to me to be the equivalent to your generate-id()version?


At first, I thought it was too.  However I learned an interesting leason
when trying this way. Consider the XML:

<Areals>
  <Areal ... >
    <Texture texture="farm.rgb" u="1" v="1" />
    <Texture texture="secondary.rgb" u="2" v="2" />
  </Areal>
  <Areal ... >
    <Texture texture="farm.rgb" u="1" v="1" />
    <Texture texture="secondary.rgb" u="2" v="2" />
  </Areal>
  <Areal ... >
    <Texture texture="farm.rgb" u="3" v="3" />
    <Texture texture="secondary2.rgb" u="4" v="4" />
  </Areal>
  <Areal ... >
    <Texture texture="farm.rgb" u="1" v="1" />
    <!-- No secondary texture -->
  </Areal>
  <Areal ... >
    <Texture texture="lake.rgb" u="5" v="5" />
  </Areal>
</Areals>


The "distinct primary textures" are:
    <Texture texture="farm.rgb" u="1" v="1" />
    <Texture texture="farm.rgb" u="3" v="3" />
    <Texture texture="lake.rgb" u="5" v="5" />

which is what the generate-id way will result in, and is what is desired in
this case.


Because of of the filter in the match:
    [0=count(preceding-sibling::Texture[1])]
"key-texture" will not have keys for "secondary" textures.

If we just did:
<xsl:variable
  name="primary-textures-using-count-method"
  select="//Texture[count(. | (key('key-texture', concat(@texture, ':', @u,
':', @v))[1]) = 1]"
  />

The when the filter is applied to the "secondary texture" nodes (nodes
excluded by the filter in the key's match), the union of "." and
"(key('key-texture', concat(@texture, ':', @u, ':', @v))[1])" is 1!  This is
because no key was built for the secondary texture nodes, so the "." gives
the node set with the secondary texture, and the "key..." gives an empty
node set.  So $primary-textures-using-count-method would have:
    <Texture texture="farm.rgb" u="1" v="1" ... />
    <Texture texture="secondary.rgb" u="2" v="2" />
    <Texture texture="secondary.rgb" u="2" v="2" />
    <Texture texture="farm.rgb" u="3" v="3" />
    <Texture texture="secondary2.rgb" u="4" v="4" />
    <Texture texture="lake.rgb" u="5" v="5" />

So that's why you need the same filter as used in the "match" on the key to
be there if you do it the count way:
<xsl:variable
  name="primary-textures"
  select="//Texture
        [0=count(preceding-sibling::Texture[1])]
        [1=count(.|key('key-texture', concat(@texture, ':', @u, ':',
@v))[1])]"
/>

Without the filter used in the "match" on the key, the count method will
give you the nodes that are part of a key (the first one of each unique
combination), plus all the other nodes matched by the XPath that aren't part
of the key.

-Daniel


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list