Channels ▼

Web Development

XSL Transformations

Source Code Accompanies This Article. Download It Now.

Zeki and Ruhsan are members of the Computer Engineering Department at Eastern Mediterranean University, Famagusta, North Cyprus. They can be contacted at [email protected] and [email protected], respectively.

For the code to run properly when sending code to be executed in remote computers, you need to make assumptions regarding the availability of certain hardware/software configurations and environments. Platform independence is thus a major issue. To address this issue, one approach is to provide an abstract machine for compiled code to run in, and to ensure that all remote users who want to run the remotely delivered programs have that environment installed. Java and .NET are examples of this approach.

However, installing environments such as these on client computers requires substantial resources. If you focus on executing code embedded in web pages (dynamic web pages with client-side scripting), you have scripting languages—say, JavaScript and VBScript—that are supported by web browsers. But these languages suffer from compatibility and standardization problems. A script in JavaScript needs to be written in more than one version if it is to run on different browsers without problems. Others, such as VBScript, enjoy support only in a limited number of browsers.

Yet another approach for executing code on the client side involves Java applets, which give you the capabilities of a full-scale programming language (Java). Still, Java applets require the Java Runtime Environment, which consumes substantial resources on the client side.

But browsers have another kind of language processor installed on them—Extensible Stylesheet Language Transformations (XSLT). XSLT stylesheets are applied to XML documents, mainly for generating XHTML pages for presentation on browsers. Thus, XSLT helps to separate content (inside XML documents) from presentation (XHTML documents). As such, XSLT is hardly a scripting language, although it does have enough features to make it suitable for the implementation of the operational semantics of an imperative language.

XIM is an XML-based programming language with imperative control features, such as assignment and loops, and an interpreter written in XSLT. XIM programs can thus be packaged with an XIM processor (as an XSLT stylesheet) and sent to the client for execution. In this article, we define the language and examine its operational semantics implementation in XSLT. To show the usefulness of packaging code with its execution engine, we present a web application that accepts user choices, gets the parameters for the requested operation, generates an XIM program that does the computation, and sends the program—together with its interpreter—to the client for execution.

The implications of this approach are significant. In principle, you don't need to be restricted to existing programming languages on the client side. Nor do you need to make assumptions about the availability of certain environments on the client side—other than that of the XSLT processor, which is already supported in all mainline web browsers. This gives you the freedom of choosing any programming language, provided its processor can be packaged and sent to the client with it.

One possible application of this idea is in the specification of the semantics of web services. A lambda expression, in a suitable XML-based syntax, which denotes the meaning of the service, can be sent to the client, as well as a lambda reduction machine to execute it. The client then either analyzes or executes the lambda expression to see if it fits the desired requirements. All this can be done without any computational burden on the server side.

Another application of this idea involves distributed computing, where the parameters for an operation are provided to a server, which in return generates a program corresponding to the specified operation and supplied parameters, packages the program and the processor of its language together, and sends them to the client for execution.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.