On Fri, May 20, 2022 at 01:45:18AM -0000, Chris Papademetrious christopher.papademetrious@xxxxxxxxxxxx scripsit:
> Regarding
> 
> > I normally use (expr1, expr2)[1] as an if-then-else for expressions evaluating to 0 or 1 node, but that arrow syntax is pretty neat. I should start using it.
> While researching the arrow operator, I came across Michael Kay's blog post at
> 
> https://dev.saxonica.com/blog/mike/2020/11/19-arrow-expressions.html
> 
> and I want that ~ operator for within-expression and across-element streaming soooo bad... I have so many xsl:variable chains I could clean up with that!

I'm not sure I want that ~ operator MORE than I want to be able to stuff
XPath expressions into macros, but if there are votes, I would vote in
favour of it.

So many template pairs; match="element[something]" and
match="element[not(something)], and something is sometimes fairly
complicated. I'd really like to be able to do

<xsl:expression-macro name="something" select="expression"/>

with the constraint that the expression has to return a string that's a
legal expression

and then use it as

match="element[%something]" and match="element[not(%something)]"

or indeed anywhere I could use a variable.  There's likely a good reason
to avoid this in terms of evaluation getting more difficult, but it'd be
syntactically useful.

(Or the lamentablly frequent [self::thiselement or self::thatelement]
chains where there's an aspect of semantic conversion going on from one
vocabulary to another.)

-- 
Graydon Saunders  | graydonish@xxxxxxxxx
^fs oferiode, pisses swa mfg.
-- Deor  ("That passed, so may this.")