XSLT 2.0 and XPath 2.0 Programmer's Reference, 4th Edition (192 page)

BOOK: XSLT 2.0 and XPath 2.0 Programmer's Reference, 4th Edition

13.06Mb size Format: txt, pdf, ePub

ads

This allows you to find a book if either the author or the ISBN is known.

However, it's worth thinking twice before doing this. Assuming the XSLT processor implements the key by building an index or hash table, rather than by searching the whole document each time, you have to weigh the cost of building the index against the cost of finding the information by a search. If your transformation only needs to find a single book using its ISBN number, it might be simpler and faster to write:

and not use a key at all. Some products (Saxon-SA for example) will even decide for themselves whether to build an index to speed up such an expression.

Multiple Definitions for the Same Key

It's also possible to have several

declarations with the same name. For example:

Now you can use the
key()
function in an expression such as:

The set of nodes this returns will be either

elements or

elements or a mixture of the two; the only thing you know for certain is that each one will be either a book with Ringo Starr as one of the authors, or a CD with Ringo Starr listed either as the composer or as a performer.

If the
use
expression were the same in each case, you could simplify this. For example to find books and CDs with a particular publisher, you could write:

This example uses the union pattern
book | CD
, which matches all

elements and all

elements. Union patterns are described on page 690 in Chapter 12.

The different definitions do not all need to be in the same stylesheet module; all the key definitions in included and imported stylesheets are merged together regardless of their import precedence.

Composite Keys

Despite all the functionality we've been discussing, one thing that isn't available directly is support for composite or multi-part keys, that is, finding an employee using both the last name and first name in combination.

The simplest way to do this is by string concatenation. Define the key like this:

and search for it like this:

key(‘k’, concat($first, ‘#’, $last))

I chose
#
here as a character that is unlikely to appear in the
firstname
or
lastname
values.

Using Keys for Grouping

In XSLT 2.0, the new

instruction (described on page 326) provides facilities for grouping nodes with common values for a grouping key, or for eliminating nodes with duplicate values for a grouping key. In XSLT 1.0, this was a much more difficult problem to solve, and you may well encounter XSLT 1.0 stylesheets that use the workaround for this problem known as Muenchian grouping, named after its inventor, Steve Muench of Oracle.

It shouldn't be necessary to use Muenchian grouping any more in XSLT 2.0. However, since it is widely used and you may have the job of converting stylesheets that use it, or of writing stylesheets that work under both XSLT 2.0 and XSLT 1.0, it's worth understanding how it works.

Say you want to group a list of employees according to their location. Typically, you want two nested loops, in pseudocode:

(details)

Muenchian grouping uses a key to identify the distinct locations and then to identify all the employees at a given location. The key is defined like this:

To find the distinct locations, scan all the employee elements, and select only those that are the first one in their location. In XSLT 2.0 you would write:

The
is
operator wasn't available in XPath 1.0, so this had to be written as:

“//employee[generate-id(.) = generate-id(key(‘k’, location)[1])]”>

The inner loop, which selects all the employees at the same location, is achieved by writing:

so the final code becomes:

“//employee[generate-id(.) = generate-id(key(‘k’, location)[1])]”>