ned786 wrote:

> Your last suggestion also works, Peter, and you are my hero. Thanks!
> The problem is fixed and it saves me a tedious maintenance chore.

My pleasure...

> If you're interested, I had to add in yet another check to make it all
> work, and the final gnarly XPath looks like this:
> 
> <xsl:variable name="wri"
> select="count(items/item[(not(@doc = 'no') and @iname !=
> starts-with(@iname,'dr')) and
>     (not(@doc = 'no') and @iname != starts-with(@iname,'hr')) and
>     (not(@doc = 'no') and @iname != starts-with(@iname,'usr')) and
>     (not(@doc = 'no') and @iname != starts-with(@iname,'szr')) and
>     (not(@doc = 'no') and @iname != starts-with(@iname,'ulr')) and
>     (not(@doc = 'no') and @iname != starts-with(@iname,'ipr')) and
>     (not(@doc = 'no') and @iname != starts-with(@iname,'br')) and
>     (not(@doc = 'no') and @iname != starts-with(@iname,'ucr'))])"/>

I'm not clear what this is trying to achieve. @iname is an attribute:
testing its inequality against a boolean like starts-with will probably
have unexpected effects, depending on whether the attribute is present
or not. If present, and starting with 'hr', then the first test should
always evaluate false. 

> Weirdly, "not(@doc = no)" worked when "@doc != 'no'" did not. But I'm
> happy.

I have the feeling I've seen this too...possibly not all processors are 
happy with negated boolean conditions involving attributes.

///Peter