Off topic, but following a train of thought: Was there a particular
reason behind the design decision that XPath *if* expressions would
require an *else* clause?

  On Jan 3, 2025, at 9:51b/AM, Bauman, Syd s.bauman@xxxxxxxxxxxxxxxx
  <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:

  o;?

> b& why empty-string-and-discard rather than just empty sequence?   
[paraphrased]
Because I didnbt think of it! Thanks for the improvement p

------------------------------------------------------------------------

  Are there significant advantages to your suggestions over the
  following?
  ( ( for $f in $fieldnames return if ( count( $fieldnames[ . eq $f ] )
  gt 1 ) then $f else '' ) => distinct-values() )[. ne '']
  I admit it is not simple, but strikes me as simpler. (Note that
  instead of the null string, one could use any string that is
  guaranteed not to be a value. I often like bbb (U+241C) or
  bbb (U+2205) for this kind of thing. One could also probably
  use a test on that bifb that only looked at preceding or
  following values of $fieldnames, which some folks might find more
  readable.)

I would hope that the map:merge is ensured to be more efficient than that
count($fieldnames[. eq $f]) gt 1 but I am not good at expression
complexity in O.. terms. And in the end with advanced XQuery engines it
is all thrown at a query optimizer/rewriter that might optimize the
expression in a way not comparable to the originable one anyway.

I don't get the

else ''

part to later have to get rid of those with [. ne ''], why can't you
simply use

else ()

to return the empty sequence?

XSL-List info and archiveEasyUnsubscribe (by email) XSL-List info and
archiveEasyUnsubscribe (by email)