RE: mixed content grouping by whitespace

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
test="pattern(section/head)".

Integration with types would also have been nice: <xsl:param name="in"
as="pattern(section/head)"/>.

Sadly, though, language decisions once made cannot easily be improved in
this way.

Regards,

Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay