Graphic Representation of the Call Processing Language (CPL) using XSLT


Columbia University Department of Computer Science

Michael Medric - mfm18@columbia.edu
Henning Schulzrinne - hgs@cs.columbia.edu
Jonathan Lennox - lennox@cs.columbia.edu

I. Introduction
This project accomplishes the task of representing any Call Processing Language(CPL) document graphically in XHTML format. The resulting XHTML is generated by XSLT documents, which are the centerpieces of this project. As any CPL document, as it is an XML-based language, is comprised of groups of nodes, outputs, and parameters, XSL/XSLT is very effective in displaying the CPL documents in a "flowchart" manner which is representative of the actions to be performed by the CPL document.

II. Structure of the XSLT Documents
The XSLT documents are based around two XSL templates that either call upon each other, or upon themselves recursively to display each node, output and parameter in the most sensible manner. In XSL/XSLT, templates are pieces of XSL and sometimes HTML code which extract the appropriated information from an XML document in order to restructure it into another form of XML. In this project, that other form of XML is HTML and the resulting script is considered XHTML. The two templates in the cpl_graphic.xsl document are:
  • root - This template is set to match the "cpl" node in each CPL document, since this node is always the first child of the root node and is required in every CPL script. The transformation is initiated with the root template. It generates the parameters for the resulting XHTML(title, text and color properties, links to Cascading Style Sheets, etc.), produces the header of the resulting XHTML document, and ends with a call to the print template on all children of the cpl node.

  • generate - The generate template performs most of the work. It generates nested HTML tables on each generation of nodes so that the resulting XHTML can have a "flow" effect to it. Between each generation of nested tables, arrows(gif files) are placed in the appropriate positions. Because nodes, outputs and parameters of the CPL document are to be treated differently and due to special cases, the generate template utilizes many test cases so that the behavior is different for each in terms of transforming the document. Essentially, the generate template calls itself recursively until a node or output has no more children.
- Another feature of the project is that it distingushes between nodes and outputs and diplays them in different fashions to make the flowchart be more realistic. This is done with the use of "choose/when" and "if" clauses. For instance, if we come across an output, rather than placing an arrow gif down and making a white cell for the node to live in, we place a straight line and place the output information(which has different text and color properties than nodes) in a transparent box and place the arrow after. This gives the effect that the node to follow is what will occur if that output happens.

III. A More In-depth Look
- When/If Conditional Statements

Throughout the XSL document, I needed to use many test cases using the "when" and "if" clauses of XSLT. Both are the same except when using the "when" clause, you are telling the processor to only choose one case in the series and order, therefore, counts. When using if, all are tested. Here is a piece of code that uses both:

<xsl:when test="name()='remove-location'">

........

<xsl:if test="name(@location)='location'">
<br/>
location :
<span class="attr">
<xsl:value-of select="@location"/>
</span>
</xsl:if>

Here we ask that when the name(name()) of the node is equivalent to "remove-location" to enter the next piece of code. Inside there, we ask if the name of the attribute(@) is location. If so, it will enter the following piece of code then continue.

- Calling the generate template

From the template that matches the "cpl" node in the XML document, we must call the generate template to perform all our node structuring. Here is the XSLT code:

<xsl:for-each select="child::*">
    <xsl:call-template name="generate"/>
</xsl:for-each>

What this code is doing is actually calling the generate template for all children nodes of the current one, which is Cpl. As a convention of CPL, every node is a child of the cpl node so we are calling it on all nodes in the XML document.

- Filling in HTML attributes on the fly

Rather than "hardcoding" all the attributes like colors and text properties into the XSL document, we can generate them on the fly so that in certain cases, table cells or certain words can be different colors or have different properties. Here is an example of how the table cells for the subaction node and sub pseudo-node get their tannish color rather than white:

<td align="center" colspan="20" bgcolor="white" nowrap="true">

.............

<xsl:when test="name()='subaction'">
<xsl:attribute name="bgcolor">#EDEDC9</xsl:attribute>

In this case, there is no "hardcoded""color" attribute for the td tag. The XSLT asks that when the name of the node is "subaction", that an attribute named "bgcolor" and having the value "#EDEDC9" be added to the resulting HTML document. The result will be:

<td align="center" colspan="20" bgcolor="white" nowrap="true" bgcolor="#EDEDC9">

IV. Other Parts of the Project
In addition to the XSLT document that I created, there are a few other deeds I had to accomplish to complete the project:
  • Create a Test Environment - this basically involved finding an XSL Processor and setting it up so I would be able to test easily and more importantly, be able to input what file was to be applied to the XSLT document, rather than "hardcoding" it. I used the Xalan XSL Processor for Java made by Apache. To use it, I wrote a Java Servlet that allowed two files, one XML and one XSL, to be inputted and transformed into HTML. Instructions on how to use the servlet in this way is in the Readme file.

  • Create a Cascading Style Sheet(CSS) - it was necessary for the properties of text and color in the resulting HTML document to be uniform. However, using simple "font" tags and attributes was not efficient as it would have made the XSLT document very bulky and it would be very difficult to change a simple text color in the future. Therefore, most of these colors and properties are read from an external CSS file called "global.css". It makes the project more modular and the properties and colors of the resulting HTML can be changed very simply.

  • Write an External JavaScript File - this was needed to implement a function called "help()" that makes the pop-up windows appear when a link is pressed for help. In more detail, the function checks browser type and screen resolution before opening the window to ensure the size is not too small or too large

V. Documents and Contacts
  • cpl_graphic.xsl - the XSLT file that transforms the CPL scripts into graphical representations. The result is XHTML.

  • global.css - the style sheet that governs the colors and text properties of most of the resulting XHTML.

  • global.js - an external JavaScript document that contains a method to pop-up help windows efficiently when a node is clicked.

  • XHTMLGenerator.java - the Java servlet class that enables the cpl_graphics.xsl file to be tested with any CPL script.

  • Readme.txt - this file contains all pertinent information for using the XSL document, the test environmen, and the Xalan processor.

  • image files - these are for the header and arrows.

Contact Information

Michael Medric - mfm18@columbia.edu
Henning Schulzrinne - hgs@cs.columbia.edu
Jonathan Lennox - lennox@cs.columbia.edu