I never fully understood why in
g-s-w/g-e-w groupings the population needs to be all nodes
and not arbitrary sequences. I wonder whether it is because
someone insisted that g-s-w/g-e-w conditions need to be
patterns and hencefore the population need to be nodes, or
whether it was the other way round. Maybe it is as it is for
"historical reasons". Or maybe they thought: if we permit an
arbitrary expression as g-s/e-w condition then we must check
that an effective boolean value may be calculated for this
expression, because it should be a yes/no decision whether a
given item starts/ends a group. Maybe they found that a
pattern that either matches or not is a more clear-cut and
comprehensible binary criterion than arcane EBV semantics, at
least for the common case of grouping nodes.
All very good questions.
All the places in the language where we apply a boolean test to a specific
node are done by patterns, and I guess that's why it was done here: it would
be odd to do one thing in xsl:number, and a different thing in
xsl:for-each-group. I don't remember a big debate about it.
In retrospect it would be nice if the bifurcation between expressions and
patterns hadn't happened, and everywhere patterns are used we had instead
used an expression evaluated with the target node as context item, taking
its effective boolean value. I suspect people wanted to write
match="section/head" to make it CSS-like, but I think one could achieve the
same with a (pseudo-?) function: match="pattern(section/head)", which could
then be used in XPath expressions anywhere, for example <xsl:when
Integration with types would also have been nice: <xsl:param name="in"
Sadly, though, language decisions once made cannot easily be improved in
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>