[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: xsl:for-each-group: start groups depending on numb
Wendell,
you wrote: While you can't restrict preceding-sibling to look only at members of the current group, you might be able to get somewhere with either of these approaches: Thank you very much for this hint! The intersection of the group members and those not having a preceding sibling of a specific sort is what I was looking for. This makes my demo template look like: <xsl:template match="B" mode="groups_at_root_level"> <B_new> <xsl:variable name="this_group" select="current-group()"/> <xsl:for-each-group select="$this_group" group-starting-with=" B|sub[not($this_group intersect preceding-sibling::A)]"> <xsl:apply-templates select="current-group()"/> </xsl:for-each-group> </B_new> </xsl:template> * If, rather than using grouping constructs to select from the nodes in the source, you processed them into temporary trees, you could construct those trees exactly the way you wanted, including nesting elements in such a way that preceding-sibling would be useful. Such as: That seems to be a neat approach, too, at least from a general point of view. However, in my case, the existence of preceding siblings is important for determining whether an item is allowed to start a group or not. So "unconditionally" starting a group on any instance of an element would yield a number of groups that would have to be resolved afterwards into members of other groups, because only looking at the siblings of the group starter will reveal that in fact it should not have fulfilled this role. xsl:for-each on "group" instances would then be quite difficult: you can't process any group after you have processed them all, because you need to make sure that you don't miss any "late" member from a group that had to be resolved... Unless you have "unstable" groups, this approach is definitely very interesting. But I'm not sure either of these are actually necessary here. You have only presented your problem in fragmentary form, so it's hard to say; but to get the result you say you want, I'd do something much simpler:> [snip] Thank you (as well as Andrew) for proposing simple and elegant solutions that accomplish the basic grouping task. Unfortunately, I can't use them because the grouping I'm doing is far more complicated. (E.g. repeated grouping based on the same element; grouping highly depends on preceding instances; dynamic creation of multiple group containers etc.) Trying to leave out the less relevant details, I crafted a demo that would just show my minimal requirements, however strange they might seem. Sorry for the confusion. Let me be more elaborate on my grouping criteria. Rather than just matching an element I always need it to meet some condition, so instead of: group-starting-with=" B|sub[not($this_group intersect preceding-sibling::A)]" I actually have more something like: group-starting-with=" B|sub[$condition1 and not($this_group intersect preceding-sibling::A[$condition2])]" What I am curious about is how I could optimize my stylesheet runtime behaviour (I'm using Saxon 8.8) by computing some values only once, e.g. using a variable declared before xsl:for-each-group, given that: - the negated expression appears several times within the attribute value (think of it like duplicating the above code for "sub"), while $condition1 is rather singular - the number of instances matching unconstrained preceding-sibling::A[$condition2] is rather large, whereas within the grouping candidates it is small or zero - the value of preceding-sibling::A[$condition2] depends, as far as I have understood, on the item that xsl:for-each-group currently examines, so it can't sensibly be evaluated beforehand Any ideas on this? Yves
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|