Replying to xsl-list with Wendell's permission, for the upward
projection connoisseurs out there. See Wendell's message that I'm
replying to below.
tl;dr: Wendell invented a slightly different upward projection method in
2013, and his method's performance for large chunks might be better than
mine. The performance needs to be systematically measured for the same
test set that I used in my XML Prague paper.
----
Hi Wendell,
Trying to wrap my head around what the stylesheet is doing.
So you are grouping leave notes from a chunking root, each group
starting with a milestone. I do this, too.
In the 'build' template, you then group the leaves according to their
ancestors' generated IDs, topmost ancestors first (not all ancestors
though, only those that are descendants of the splitting root).
At $level=1, (ancestor::* except $from/ancestor-or-self::*)[$level] will
give the child of $here that is an ancestor of the current leaf.
So we are putting the leaves that have the top-level ancestor below
$here in each group.
Line 41: $copying is this top-level ancestor below $here (at least for
$level=1)
If it is empty ($here is current node's parent), the grouping key for
group-adjacent is the zero-length string, so the complete group from the
group-starting-with will be output.
If it isn't empty, the top-level ancestor will be copied.
Then the build template will be called for each group with $level=2,
that is, the grandchildren of $here will be reproduced for each current
group of leaves.
Ok, I think I get it.
I'd say this is an alternative way to do upward projection, and it is
definitely independent discovery. We have been using this method since
2010, but we didn't mention it publicly before 2014.
And I can imagine that your solution doesn't suffer from the performance
degradation for large chunk sizes that I described in the paper
(https://archive.xmlprague.cz/2019/files/xmlprague-2019-proceedings.pdf#page=360).
What my method did was to transform $here with a tunneled parameter,
$restricted-to, that contains the generated IDs of all $here descendants
that are simultaneously ancestor-or-selfs of each leaf group. For each
node, it decides whether it is in the current $restricted-to set, and
only then it is output. And these comparisons become increasingly
expensive the larger the chunks become (the more strings $restricted-to
contains). This may be a Saxon implementation detail, and we should
calculate the results for Saxon 10, too.
We should re-implement the code
(https://subversion.le-tex.de/common/presentations/2019-02-09_xmlprague_xslt-upward-projection/examples/pb/)
with your method and carry out the same measurements. If your method
proves to be more efficient for large chunks, it will justify another
XML Prague presentation, at least for a 15-minute slot. Or at the very
least another post to this list.
Gerrit
P.S.: No deer here, only cat & dog. Also no rain, only sunshine at max.
30 °C (86 °F) during the day.
On 16.08.2020 17:07, Wendell Piez wrote:
Holla Gerrit,
Is this an example of upward projection? (see template name='build')
https://github.com/wendellpiez/MITH_XSLT/blob/master/xslt/p-promote.xsl
I am curious if it is a case of independent discovery. In any case, as
you well know, the problem occasionally rears its ugly head in the TEI
context, indeed this is actually a species of overlap (a natural
enough occurrence that is found to be 'unnatural' by XML).
Greetings from Maryland, where today it is raining and we have four
deer in our backyard this morning.
Cheers, Wendell
--~----------------------------------------------------------------
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
--~--