Deploying XSLT on the Client

When deploying XSLT on the client, you must ensure that all clients use the same MSXML version, use version-dependent ProgIDs from a script or another COM-enabled programming language to link your XSLT style sheets with source XML documents. This is not a problem for MSXML 3.0, all currently supported Windows system already has MSXML 3.0 pre-installed. MSXML 6.0 is in same situation except that on Windows Server 2003 system you must ensure that MSXML 6.0 has been manually installed.

Advantages of Transforming on the Client

There are several reasons for having client-side deployment of an XSLT solution. The primary reason is to reuse the client-side caching to avoid downloading the same documents repeatedly. For example, you might have several XML documents that use the embedding method to link to the same XSLT style sheet. With client-side caching, the style sheet is downloaded once and only once. The next downloaded XML document will use the cached version of the style sheet. This helps to reduce download time.

While server-dominated systems have a limited ability to save state, session states can be maintained on the client with the help of client-side scripting. This makes your applications easier for Windows users to use. You can also take advantage of capabilities of Internet Explorer such as behaviors, drag and drop interactions, DHTML, ActiveX controls, and more.

Lastly, by using the ServerXMLHTTP component in client-side scripting, you can send XML information directly to the client without forcing a page update. The XMLHTTP component and XSLT are a powerful combination. They allow you to pull in just the information that you need from the server, transform it to a suitable form of output, reduce the bandwidth of information being transmitted, and reduce the loss of context that converting XML into HTML entails.

See Also

Deploying XSLT in Internet Explorer
Deploying XSLT on the Server