On Fri, May 20, 2022 at 01:45:18AM -0000, Chris Papademetrious
christopher(_dot_)papademetrious(_at_)synopsys(_dot_)com 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(_at_)gmail(_dot_)com
Þæs oferéode, ðisses swá mæg.
-- Deor ("That passed, so may this.")
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--