This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 4921 - [XSLT 2++] Combining group-starting-with and group-ending-with
Summary: [XSLT 2++] Combining group-starting-with and group-ending-with
Status: CLOSED LATER
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 (show other bugs)
Version: Recommendation
Hardware: PC Windows XP
: P2 enhancement
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-08-08 11:53 UTC by Michael Kay
Modified: 2014-05-15 14:00 UTC (History)
0 users

See Also:


Attachments

Description Michael Kay 2007-08-08 11:53:07 UTC
XSLT 2.0 Future enhancement suggestion

A use case came up on the mulberry xsl-list today for turning an input sequence supplied in the form into a true hierarchy

<start/>
<item/>
<item/>
<start/>
<item/>
<end/>
<item/>
<end/>

It occurs to me that there is no reason why we shouldn't allow group-starting-with and group-ending-with attributes to coexist on xsl:for-each-group; it would be a simple change to remove this restriction, and would make the solution for this use case much more natural.
Comment 1 Sharon Adler 2007-10-10 19:37:44 UTC
considered as an enhancement request for VNext
Comment 2 Michael Kay 2010-07-16 13:00:03 UTC
The WG's current thoughts are not to do this as proposed, but rather to give thought to more powerful mechanisms for positional grouping (influenced perhaps by the tumbling/sliding windows being introduced in XQuery). One possibility is to introduce accessors such as next() and previous() to refer to items in the focus sequence adjacent to the context item - but this could create problems if these are dynamically scoped (the system needs to know whether or not it needs to maintain this information). Needs further study (and use cases).
Comment 3 Michael Kay 2010-07-20 23:02:26 UTC
Some further ideas on this.

(a) Extend the focus by providing next() and previous() accessors to return the item after/before the context item in the sequence being traversed. With the proviso that (i) these are only available in xsl:for-each, xsl:for-each-group, and xsl:iterate, and (ii) they must be used lexically within that instruction, so that the compiler can determine that it needs to maintain this information.

(b) Extend the options for positional grouping on xsl:for-each-group:

(b1) Allow group-starting-when and group-ending-when as alternatives to group-starting-with and group-ending-with. The attributes are expressions evaluated with the focus pointing to the item being tested. For example group-starting-when="position() mod 2 = 0" starts a new group on even-numbered items.

(b2) If both group-starting-with/when and group-ending-with/when are specified, then groups can overlap. For example group-starting-when="true()" group-ending-when="count(current-group()) = 3" starts a new 3-item group at every item in the sequence (but see next point).
 
(b3) Attribute match-at-boundary=yes|no determines whether the first item is deemed to match the group-starting-with pattern and the last item is deemed to match the group-ending-with pattern. Default is yes for compatibility.

(b4) current-group-start-position() returns the position of the initial item of the current group in the population; current-group-end-position() returns the position of the final item of the current group in the population. 

Together, I believe these enhancements provide essentially all the capability of XQuery's sliding/tumbling windows. We'll need to test this by coding up the XQuery windowing use cases.
Comment 4 Michael Kay 2011-06-09 14:52:58 UTC
The minutes from the F2F in Prague (March 2011) record as follows:

MSM suggested that there is an analogy between the overlapping groups of comment 3 and possibilities for grouping on the basis of regular expressions (over an alphabet of QNames) with capturing sub-expressions. He thought that this would be useful functionality which would address a weakness in the current version of our specs. SCA asked that MSM send email explaining what he had in mind.
SCA asked about the prospects of further work; MK suggested we might need to begin setting a high bar for enhancement requests.

RESOLVED: mark bug 4921 as Later.

Which I am now doing.