Subject: Re: [xsl] Sibling recursion? From: "Graydon graydon@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> Date: Thu, 3 Mar 2022 16:24:50 -0000 |
On Thu, Mar 03, 2022 at 04:07:21PM -0000, David Birnbaum djbpitt@xxxxxxxxx scripsit: > My input is <p> elements with mixed content, some of which is <q> > elements (and other element types). Consecutive <q> elements inside a > <p> should be merged into a single <q>, where consecutive means either > immediately following (with no intervening nodes) or with an > intervening whitespace-only text node. When I've had to do similar things (notably for hierarchy flattening), I've used a recursive function, often with a "write out this accumulated sequence of things which should be wrapped or otherwise together" helper function. This function gets called on the sequence of nodes found in each p element, and contains a choose which starts with "input sequence empty? stack empty?" and "input sequence empty, still stuff in the stack?" tests and then starts doing specific things. (For example, your "this is a whitespace only text node" case would throw that node away.) This uses head() and tail() a lot and I find it starts off feeling incomprehensible and then abruptly makes sense. It's also easy to extend if new elements show up in later versions of the content. If that doesn't make sense I can dig up an example. -- Graydon Saunders | graydonish@xxxxxxxxx ^fs oferiode, pisses swa mfg. -- Deor ("That passed, so may this.")
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Sibling recursion?, David Birnbaum djbpi | Thread | Re: [xsl] Sibling recursion?, Michael Kay mike@xxx |
Re: [xsl] Sibling recursion?, Norm Tovey-Walsh ndw | Date | Re: [xsl] Sibling recursion?, Michael Kay mike@xxx |
Month |