WebReference.com - Part 1 of chapter 12 of XSLT Developer's Guide, from Osborne/McGraw-Hill (1/6)
XSLT Developer's Guide
Client is a broad term that may mean different things to different people. It may refer to a presentation conduit such as a web browser or a WAP microbrowser embedded in a PDA or a cell phone. In a different context, it may refer to a hardware device such as a PC, PDA, or cell phone. In the EAI or B2B realm, it might refer to a client application that subscribes to data published by another application. For the purpose of the present discussion, we will use the term client to refer to a web browser or microbrowser.
In the same vein, using XSLT on the client side means pushing the stylesheet along with the source XML document to the client and giving the client the freedom to interpret it. Of course, this also means delegating the responsibility of parsing the source file and the stylesheet to the client as well, and therein lies the crux of the discussion.
There are two questions to be reckoned with here. The first is whether the client is capable of processing XSLT, which is what we will discuss in this section. The second question is whether you should architect an application so that XSLT processing becomes the client's responsibility. We will defer the second question until the next section.
Clients Capable of XSLT Processing
Until recently, the question as to whether you should use client-side XSLT was really a nonquestion since the browsers used by a large fraction of the populationÂthat is, Internet Explorer (IE) and Netscape Navigator (NN)Âcould not process XSLT, at least not without specialized DLLs or plug-ins. To be sure, XSLT-compliant browsers have been available for some time (for example, the VSMS Jumbo, W3C Amaya, InDelv XML, and MultiDoc Pro 2.1 browsers), although their users have been mainly serious technophiles.
Even now, one of the hotly debated questions in the XML world is whether client-side XSLT is ready for widespread use. From what we have seen in many of these spirited debates, it appears that a definitive and absolute answer is unlikely to emerge any time soon. However, one thing is clear: the major browsers have been steadily improving their support for XSLT. We are at a point where many, if not all, key XSLT features are supported by the browsers. Thus, we can argue that as a computing community, we are moving in the right direction, and sooner or later we may expect near-complete compliance with the XSLT specifications within the web clients.
Thus, for the rest of the discussion in this chapter, we will consider a browser to be XSLT compliant for all practical purposes if it adheres to most of the XSLT specification.
Using Client-Side XSLT Processing
Delegating the XSLT processing responsibility to a client is a rather simple matter. When the source
XML file (say,
auth.xml) and the corresponding XSLT stylesheet (say,
are pushed from the server to the client, the connection between them is established in the preamble
to the source tree document, as shown in the following example. Note the use of the MIME media type
text/xml, which we will discuss shortly.
<?xml version="1.0"?> <?xml-stylesheet type="text/xml" href="auth.xsl"?> <!-- data specifications begin --> <All_authors> <Author AuthID="77"> <Name> <First_name> ... </Author> </All_authors> <!-- data specifications end -->
Thus, in an n-tier application, when the browser makes a request to the web server that requires
auth.xml, the server will send out to the web browser both the source tree
auth.xml and the stylesheet to which it makes a reference: that is,
auth.xsl. Then it is the browser's responsibility to render the data on the web
page by interpreting the XSLT stylesheet. For those of you familiar with cascading style
sheets (CSS), this is not much different from the use of the MIME media type
as shown in the following code sample:
<?xml-stylesheet type="text/css" href="auth.css"?>
Created: May 28, 2002
Revised: May 28, 2002