Recently I needed to create a Web service that would allow an outside organization to enter orders on a legacy system using XML. My initial optimism about this project was squashed by the reality of dealing with the limitations of a system that was designed and coded sometime during the Carter Administration. While I had anticipated that the XML would need to be massaged in order to produce something that my mainframe counterpart could use, I hadn't foreseen exactly what constituted an order on both the outside organization and the legacy application.
Most of the major philosophical differences in what constitutes an order stemmed from the fact that the outside organization stored customer information on the line level while the legacy application stored customer information on the order level. This means that every line on the inbound order could conceivably be a different customer, a concept that was not contemplated during the Carter years. Another issue which only served to compound this problem is that the legacy system only supported a single ship to address, a single bill to address and a single carrier per order. What had started out as a relatively simple Web service quickly began to snow ball into both a major project and a major headache.
After a brief delusional moment where some kind of convoluted C# program was considered for splitting an inbound order into something the legacy system could handle, I decided to try a more elegant approach, XSLT and Muenchian grouping.
A downloadable version of this article is available in PDF form from the TechRepublic Download Center. The PDF version includes the article and all of the code listings in a printer-friendly format.
by, and named after, Steve
Muench of Oracle, the Muenchian
grouping method uses the xsl:key element and the key() and generate-id()
functions to determine keys that are used to retrieve nodes. To illustrate how
this works let's start with the XML document shown in
Examine the components
At first glance Muenchian grouping doesn't appear to make much sense, how can an xsl:key element along with a couple of functions group the nodes in an XML document? In order for the inner workings to become clear it is necessary to examine the individual components, only then will the simple elegance become clear.
The xsl:key element is a top-level XSLT element that is used to declare a named key. The element's match attribute defines the node returned from the key() function while the use attribute defines the key itself. The purpose of the predicate, , is to insure that only the first instance of each key is returned. This means that each key is used only once instead of the number of times that the key occurs. Without this predicate, if a particular key occurred twice the associated elements would be doubled, three times tripled, and so forth.
The generate-id() function is the final piece, it returns a string that uniquely identifies a node, regardless of how the node is obtained. So, if generate-id(.) is equal to generate-id(key('keyGroup',customer)) is true then both nodes are the same node, just obtained differently. It is also important to remember that while the string is always unique, there is no guarantee that id will be equal from execution to execution.
Occasionally, when grouping, it is necessary to group information on more than one criteria. Consider the XML document from Listing A. Wouldn't it make sense to, in addition to grouping on customer, group on carrier, ship to address, and bill to address? Seems easy enough, just add another xsl:key element and another key() function, right? Wrong!
When using Muenchian grouping only one xsl:key
element and key() function is ever
needed. Multiple grouping criteria is handled through the addition of the concat() function which is used to concatenate
the various nodes and/or elements to produce a single key. With this in mind,
How far can Muenchian grouping using concatenated be taken? Personally I've used this technique to group information based upon eleven different criteria. The resulting XSLT was, when printed not quite three pages long, which while impressive for XSLT, was thousands of lines shorter than programs written in traditional programming languages.
An adaptable solution
While this may, at first, seem like a rather specific application it is one of those tools that can be readily adapted to other uses. I recommend playing with the examples provided here in order to become comfortable with this technique. In addition, you may want to purchase a copy of XMLSPY from Altova, which was used to produce and test the examples provided here. Not only is it a slick professional XML editor, it allows the developer to step-through an XSLT element by element, which comes in handy when debugging Muenchian grouping.