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.
