Page 180 - Building Digital Libraries

Sharing Data—Harvesting, Linking, and Distribution

deprecated, popular XSLT processors like Saxon no longer directly support
this specification, but will continue to process version 1.0 documents via
the 2.0 specification (which is backwards-compatible). Within the library
community, most XSLT transformation documents are still written using
the version 1.0 specification.
So, if the difference between XSLT versions is mainly the feature set,
what does that entail? Essentially, it comes down to higher-level processing
instructions. In XSLT version 1.0, data functions were primarily limited
to simple math, string, and date functions. XSLT selection and grouping
elements were limited to “if . . . then” statements, select statements, “for
. . . next,” and choose statements. The 1.0 specifications lack of grouping
or matching functions would force stylesheet designers to create custom
templates that replicated these operations, or encouraging XSLT stylesheet
designers to rely on built-in extensions found in specific XSLT engines,
which limited the portability of the solution. XSLT 2.0 filled in many of
these gaps, providing true matching and grouping language elements, as
well as better regular expression support. And XSLT 3.0 moves the stylesheet
language closer to a true programming language, introducing error trap-
ping and the ability to utilize functions as parameters in other functions,
and introducing elements of compile-time processing into the language.
In the digital library space, XSLT wears many hats. By and large, most
metadata transformation occurs through the use of XSLT processing, given
the relatively easy language elements and availability of the processing
engines. But XSLT is also used within some systems in place of HTML or
other language elements to generate public-facing pages. Probably the best
example of this use is found in the DSpace community. DSpace provides
a number of different user interface technologies. There is a legacy JSP
(JavaServer Pages) interface that is a mixture of pure Java and HTML. Prior
to DSpace 2.0, the JSP user interface was the most common. Today, DSpace’s
XMLUI provides an XSLT-driven interface engine. Using this model, user
interface elements are created using XSLT to manipulate the raw XML
produced by the application. The shift to an XSLT model was important for
libraries because it broadened the number of individuals who could work
with the digital library interface, shifting the work from an organization’s
Java developers to more staff who are experienced in more traditional web
development.

XQuery

Within the library community, exposure to technologies other than XSLT
for processing XML data is unlikely. XSLT simply meets the needs of
most organizations. While XSLT has some significant disadvantages when
working with large XML datasets, the majority of operations that libraries
perform on XML content rarely push against these limits. However, out-
side the library community, the use of XSLT is often paired with another
technology—XQuery.

165