Here is the Muenchian grouping solution you are looking for.
Going from the original XML you provided, I thought grouping by AreaID would be enough, but it turns out that a second grouping by UnitID is also needed.
Here is my modified XSLT 1.0 solution. It's not a lot more complex than the original solution:
<xsl:stylesheet
version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
>
<xsl:key name="kPlanByArea" match="Plan"
use="@AreaID" />
<xsl:key name="kPlanByAreaAndUnit" match="Plan"
use="concat(@AreaID, ',', @UnitID)" />
<xsl:template match="/">
<xsl:apply-templates select="Root/Plans" />
</xsl:template>
<!-- main template -->
<xsl:template match="Plans">
<ol>
<!-- group by '{@AreaID}' (note the template mode!) -->
<xsl:apply-templates mode="area-group" select="
Plan[
generate-id()
=
generate-id(
key('kPlanByArea', @AreaID)[1]
)
]
">
<xsl:sort select="@AreaID" data-type="number" />
</xsl:apply-templates>
</ol>
</xsl:template>
<!-- template to output each '{@AreaID}' group -->
<xsl:template match="Plan" mode="area-group">
<li>
<xsl:value-of select="concat('Area ', @AreaID)" />
<ol>
<!-- group by '{@AreaID},{@UnitID}' -->
<xsl:apply-templates mode="unit-group" select="
key('kPlanByArea', @AreaID)[
generate-id()
=
generate-id(
key('kPlanByAreaAndUnit', concat(@AreaID, ',', @UnitID))[1]
)
]
">
<xsl:sort select="@UnitID" data-type="number" />
</xsl:apply-templates>
</ol>
</li>
</xsl:template>
<!-- template to output each '{@AreaID},{@UnitID}' group -->
<xsl:template match="Plan" mode="unit-group">
<li>
<xsl:value-of select="concat('Unit ', @UnitID)" />
<ol>
<xsl:apply-templates select="
key('kPlanByAreaAndUnit', concat(@AreaID, ',', @UnitID))/Part
">
<xsl:sort select="@UnitID" data-type="number" />
</xsl:apply-templates>
</ol>
</li>
</xsl:template>
<!-- template to output Parts into a list -->
<xsl:template match="Part">
<li>
<xsl:value-of select="concat('Part ', @ID, ' (', @Name ,')')" />
</li>
</xsl:template>
</xsl:stylesheet>
Since your XML is missing it, I added a UnitID to group on:
<Plan AreaID="1" UnitID="86">
<Part ID="8651" Name="zzz" />
</Plan>
And here is the output:
<ol>
<li>Area 1
<ol>
<li>Unit 83
<ol>
<li>Part 9122 (foo)</li>
<li>Part 9126 (bar)</li>
</ol>
</li>
<li>Unit 86
<ol>
<li>Part 8650 (baz)</li>
<li>Part 8651 (zzz)</li>
</ol>
</li>
<li>Unit 95
<ol>
<li>Part 7350 (meh)</li>
</ol>
</li>
</ol>
</li>
<li>Area 2
<ol>
<li>Unit 26
<ol>
<li>Part 215 (quux)</li>
</ol>
</li>
</ol>
</li>
</ol>
Since you seem to have a hard time with the XSL key, here my attempt of an explanation:
An <xsl:key> is absolutely equivalent to the associative array (map, hash, whatever you call it) known to many programming languages. This:
<xsl:key name="kPlanByAreaAndUnit" match="Plan"
use="concat(@AreaID, ',', @UnitID)" />
generates a data structure that could be expressed in JavaScript like this:
var kPlanByAreaAndUnit = {
"1,83": ['array of all <Plan> nodes with @AreaID="1" and @UnitID="83"'],
"1,86": ['array of all <Plan> nodes with @AreaID="1" and @UnitID="86"'],
/* ... */
"1,95": ['array of all <Plan> nodes with @AreaID="1" and @UnitID="95"']
};
The function to access the data structure is called key(). So, this XPath expression:
key('kPlanByAreaAndUnit', concat(@AreaID, ',', @UnitID))
is the logical equivalent of (in JavaScript, again):
kPlanByAreaAndUnit[this.AreaID + ',' + this.UnitID];
returning an array (a node-set, more correctly) of all nodes matching the given key string (the key is always a string). This node-set can be used like any other node-set in XSLT, i.e. like the ones you retrieve through "traditional" XPath. This means you can apply conditions (predicates) to it:
<!-- first node only... -->
key('kPlanByAreaAndUnit', concat(@AreaID, ',', @UnitID))[1]
<!-- nodes that have <Part> children only... -->
key('kPlanByAreaAndUnit', concat(@AreaID, ',', @UnitID))[Part]
or use it as a base for XPath navigation:
<!-- the actual <Part> children of matched nodes... -->
key('kPlanByAreaAndUnit', concat(@AreaID, ',', @UnitID))/Part
and so on. This also means we can use it as a "select" expression for <xsl:apply-templates>, and we can use it as a base for grouping. Which leads us to the core of the above stylesheet (if you have wrapped your head around this one, you've understood the rest of the solution as well):
key('kPlanByArea', @AreaID)[
generate-id()
=
generate-id(
key('kPlanByAreaAndUnit', concat(@AreaID, ',', @UnitID))[1]
)
]
In JavaScript again, this could be expressed as:
// the result will be a node-set, so we prepare an array
var selectedNodes = [];
// "key('kPlanByArea', @AreaID)"
var nodeSet = kPlanByArea[this.AreaID];
// "[...]" - the [] actually triggers a loop that applies
// the predicate expression to all nodes in the set, so we do:
for (var i = 0; i < nodeSet.length; i++) {
// use the current node for any calculations
var c = nodeSet[i];
if (
// if the current node === the *first* node in kPlanByAreaAndUnit...
generateId(c)
==
generateId(kPlanByAreaAndUnit[c.AreaID + ',' + c.UnitID][0])
) {
// ...include it in the resulting selection
selectedNodes.push(c)
}
}
After the expression is done, only those nodes are selected that are the respective first ones with a given "AreaID, UnitID" combination - effectively we have grouped them on their "AreaID, UnitID" combination.
Applying a template to this node-set causes every combination to appear only once. My <xsl:template match="Plan" mode="unit-group"> then retrieves the full list again to achieve complete output for each group.
I hope the use of JavaScript to explain the concept was a helpful idea.