|
Extensible Stylesheet Language Transformations help you separate XML content from presentation.
April 05, 2007
URL:http://www.drdobbs.com/web-development/xsl-transformations/198800555
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.
We can regard an XIM program as an abstract syntax tree representation of a program written in a high-level concrete imperative language with variables of type float, expressions involving arithmetic operators, the usual Boolean expressions, an assignment statement, one conditional construct (if-then-else), and one iteration construct (while). The formal syntax of XIM is specified using an XML Schema (available electronically; see "Resource Center," page 5). XIM constructs are straightforward. Every statement element in XIM has a @seq attribute, which acts like the symbolic address of the element. The @next attribute gives the address of the next instruction to be executed. In <while> and <if> constructs, attributes @true_next (@false_next) determine control flow when the condition is true (false). The values of these attributes are automatically generated, using XSLT, before execution starts. Listing One is an XIM program that computes 5!, demonstrating the use of assignment and while constructs. Listing Two is the same program in pseudocode.
<?xml version="1.0"?>
<program>
<vars>
<var_declare name="fact"> 1 </var_declare>
<var_declare name="last"> 0 </var_declare>
<var_declare name="nb"> 5 </var_declare>
</vars>
<main>
<assign varn="last">
<var_use name="nb"/>
</assign>
<while>
<condition>
<boolop opname="gt">
<var_use name="last"/>
<num> 1</num>
</boolop>
</condition>
<statement_list>
<assign varn="fact">
<op opname="*">
<var_use name="fact"/>
<var_use name="last"/>
</op>
</assign>
<assign varn="last">
<op opname="-">
<var_use name="last"/>
<num> 1</num>
</op>
</assign>
</statement_list>
</while>
<end/> <!-- program termination -->
</main>
</program>
var fact <-- 1
var last <-- 0
var nb <-- 5
begin
last <-- nb
while (last>1) do
fact <-- fact*last
last <-- last-1
end while
end
Operational semantics specify the meaning of a program in a source language by giving rules for how the state of an abstract (or real) machine changes for each construct of the source language. The states of the abstract machine can be represented as < code, memory > pairs (called "configurations"), where code represents the remaining computation, and memory is the current contents of the memory of the abstract machine. A transition function specifies the transition from one configuration of the machine to the next. The transition function defines the operational semantics of the language and can also act as an interpreter for it. Using XSLT for specifying the operational semantics of programming languages, a configuration consists of the memory, program, and current value of the "program counter," all inside an XML document. The transition function is specified as XSLT templates.
An XSLT stylesheet implements the operational semantics of XIM. Before execution starts, the stylesheet transforms the XIM program to make it ready for interpretation. First the "program counter" is introduced as a variable in the program, and symbolic addresses are inserted into instructions as @seq attributes. Then the values in the @next, @true_next, and @false_next attributes of the instructions are determined and inserted into the code. These attributes specify the address of the next instruction to execute, as in attribute grammars used in syntax-directed compilation. After the initialization stage, other templates are applied to the transformed XIM program to execute it. The application of templates is an iterative process, which stops when the next instruction is the <end> element.
The top-level template (available electronically) of the stylesheet matches the root and performs the application of templates for initialization and interpretation. Templates for inserting the program counter and calling the Sequencer template (available electronically) insert the "program counter" as an XIM variable named PC and symbolic addresses as @seq attributes. The Sequencer template (available electronically) achieves the insertion of symbolic addresses through the use of the <number> element of XSLT. Values in the @next, @true_next, and @false_next attributes are then inserted by templates that perform a case-by-case analysis of a given node to determine its type, inspect its position relative to other instructions, and set the control flow information as jump addresses accordingly. The template for the implementation of the iterative steps is Interpret and the template for determining the type of current instruction and calling the corresponding template for its execution is Execute; both templates are available electronically. The Assignment template (also available electronically) receives an assignment statement as an XML subtree in the $c parameter. The template also has access to the XML document as a whole via the $prg parameter. The name of the program variable to whom a new value is to be assigned is copied into the XSLT variable $varname. The whole <memory> element of the XML document is recreated to reflect the updated value of the variable, as well as the updated value of the "program counter" PC variable. The template Construct (available electronically) handles the execution of <while> and <if> statements. The instruction, which is an <if> or <while> construct, comes into parameter $c and the code of the program as a whole comes in parameter $prg. The truth value of the condition is determined and assigned to the XSLT variable $condition. Then the <memory> element, with all its children except the PC, is copied. The value of the PC variable is updated depending on the truth value of $condition. When it is "true," the value of the @true_next attribute of the <condition> child of the context node is assigned to the PC variable. Otherwise, the value of the @false_next attribute is assigned to it.
The Evaluate template (available electronically), takes a parameter $n holding an XML subtree representing an expression. Figures 1 and 2 are arithmetic and Boolean expressions, respectively. This template also has access to the whole XIM program in the parameter $p. It first checks whether the incoming parameter is a numerical literal (<num>), a variable (<var_use>), or a complex expression (<op> or <boolop>). If the incoming expression in parameter $n is a <num>, it returns the content of the <num> element. If it is a <var_use> element (an r-value), the value of the <var_declare> element referenced by <var_use> is returned. If the incoming expression is an <op> or <boolop>, the type of operation required is determined from the @opname attribute. The possible values in the @opname attribute for the <op> element are *, +, -, /, intdiv, and mod, while the options for <boolop> are or, and, not, lt, gt, eq, ne, ge, and le, which have their conventional meanings.
Boolean expressions are evaluated fully in the same manner as arithmetic expressions (see the code fragment from template Evaluate that handles Boolean expressions, available electronically).
In our sample application, the user decides on a function to invoke (one of "Factorial," "Fibonacci," "IsPrime" and "nthPrime"), provides the parameter, and clicks on the button corresponding to the desired operation. The basic structure of the code that processes the client input is:
First, the stored "prepackaged" XIM code for the requested computation (whose only missing part is the input parameter value) is loaded into an XmlDocument object and the parameter supplied by the user is inserted into the code at the correct spot. Then the processing instruction indicating the name of the stylesheet (the XIM interpreter) to be applied to the document is inserted into the code. The resulting code in the object is stored in an XML document, and the client browser is redirected to this XML document. To demonstrate what happens when the client supplies a parameter and makes a choice, this code processes a "factorial" request:
private void FactBtn_Click(object sender, System.EventArgs e)
{
XmlDocument xmlDoc=new XmlDocument();
xmlDoc.Load("c://inetpub/wwwroot/xim/fact5.xml");
XmlElement var_n=xmlDoc.CreateElement("var_declare","");
var_n.InnerText=TextBox1.Text;
var_n.SetAttribute("name","nb");
// Adding name attribute to variable element
// Appending client input as a variable to XIM code
// for factorial computation
xmlDoc.DocumentElement.FirstChild.AppendChild(var_n);
XmlProcessingInstruction newPI;
// Processing instruction to declare stylesheet name
String PItext = "type='text/xsl' href='interp.xsl'";
// Assigning the name of the interpreter
// stylesheet to processing instruction
newPI = xmlDoc.CreateProcessingInstruction
("xml-stylesheet", PItext);
// Add processing instruction node to the document
xmlDoc.InsertBefore(newPI, xmlDoc.DocumentElement);
xmlDoc.Save("c://Inetpub/wwwroot/XIM/test.xml");
// Save the modifications to the XIM code
// Redirectng the client response
// to the just created XIM file
Response.Redirect("http://194.27.78.64/XIM/test.xml");
}
See Figure 3 for the result of the interpretation on the client machine of the factorial function, applied to number "20."
XMILE (pizza.cs.ucl.ac.uk/xmile/) is an XML-based imperative language. Its goal is to keep mobile information devices synchronized by providing updates without stopping execution. Programs written in XMILE are transferred in source form, then interpreted on the remote host, which has the interpreter implemented in Java. In XMILE's case, the interpreter is already existent/installed in the clients. In our case, the interpreter, implemented in XSLT, is bundled together with the program.
In his book C++/XML (New Riders Publishing, 2001), Fabio Arjona Arciniegas describes how to build interpreters for XML-based scripting languages.
In "Towards SMIL as a Foundation for Multimodal, Multimedia Applications" (published in the Proceedings of EUROSPEECH 2001), Jennifer L. Beckham, et al., introduce ReX, which is a simple reactive programming language based on XML.
Superx++ (xplusplus.sourceforge.net/indexPage.htm) is an XML-based object-oriented language whose runtime environment is developed using C++ by Kimanzi Mati.
Sending code over the Internet to be executed on client web browsers represents one more degree of freedom than what is currently available, which is that the language available in the browsers is fixed, and only programs written in that language, and data to be used by that program, are sent to the browser.
The possibility of bundling together the language processor with the program and data opens up tremendous opportunities, allowing special purpose languages to be developed and used without requiring the end users to install additional components to their web browser. This also largely eliminates compatibility problems stemming from the unstandardized nature of scripting (and other) languages built into web browsers currently in use.
Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.