Among off-list responses to my posting re grouping via keys in this thread
was a note from Wendell suggesting the application of what, with
characteristic generosity, he described as a "tweaklet", but is in truth the
correction of a pretty major goof on my part. As tends to be the case with
such goofs at their very worst, the effect isn't visible on the sample
document, but it would have definitely unwanted consequences in a longer
one.

It concerns my (mis)use of the XSLT union operator "|". Ironically in my
production code (nothing to do with xhtml generation, but everything to do
with grouping) from which I adapted the example for posting, I had it right;
but somehow I persuaded myself while writing the posting that the original
formulation could be "abbreviated". Big mistake.

My error is at the point where I say

> So, leaving our predicate in place to filter the <p>s as
> before, we extend the XPath to select children of those filtered<p>s,
> whether they are text nodes or element children (along with any text
> descendants those children may have), giving:
> match = "p[q/@rend='block']/text()|*"


The narrative part is correct, but the sample XPath doesn't do what I claim.
In XSLT, the operator "|" evaluates  the XPath expressions either side of it
and returns the union of the two resultant nodesets. What I wanted was the
union of all the immediate text children of <p>s with at least one q child
having @rend='block' (which my expression left of the "|" indeed matches)
and the element children of <p>s matching the same filtering predicate. But
what I stupidly placed to the right of the union operator in my attempt at
terseness (!) was the bare expression "*", which of course selects all
elements. To make the right hand term select only what I intended to select,
it needs to become

"p[q/@rend='block']/text() | p[q/@rend='block']/*"

Without that correction (which of course needs to be made in the actual
sheet as well as in my preamble, so I have corrected the zipped version in
the download), the sheet as presented, if fed a document with more than one
<p> of the type envisaged, would misbehave badly when outputting the grouped
contents of what was intended to be the first newly-minted html<p> in the
first XML <p> containing a child <q> that meets the rend= condition. That
<p> would alarmingly receive the content of all the elements in the document
preceding the <q> that immediately followed it. The later grouped <p>s would
still then all emerge fine, but not before the faith of any reasonable
person in my competence, or the usability of XSLT, or maybe both, had been
badly shattered.

Michael Beddow