XAK and XML Refinement
XAK (pronounced “sack”) is a tool for composing base and refinement documents in XML format.
This document contains sections on the following topics:
Introduction XAK XAK2 Download Reference
Introduction
The need for XAK arose when we were developing product lines for web applications using AHEAD [1]. An unusual characteristic of web applications is that a sizable fraction of their definition is not Java or Jak source, but rather XML specifications [2] (e.g., JSP, HTML, and STRUTS control flow files). Thus, it is common for a feature of a web application to contain XML documents (base or refinements) and Jak source (base or refinements). We began our work at a time when AHEAD did not have a language for XML document refinement and tool for XML document composition. This lead to the creation of XAK.
XAK
We experimented with several ways to specify XML refinements. Initially we viewed an XML document merely as a tree of nodes. To refine a tree, we used XPath to identify a particular node, and used before, after, around, or override designators to insert a tree of XML nodes before, after, or around the target node, or to replace the tree rooted at that node.
Constant Document
A constant is any well-formed XML document/file that may or not have associated a schema or a DTD for validation. The following is a fragment of typical example of a constant contained in file base-build.xml.
<project name="FOPTools" basedir="." default="all"> <property name="project.title" value="FOP Tests"/> <target name="test.ahead" depends="initialize,require" description="Run tests on the AHEAD toolsuite"> <path id="id.path.test.ahead"> <fileset dir="ahead/build/lib"> <include name="balicomposer.jar"/> <include name="bali2jak.jar"/> </fileset> </path> <!-- more code --> </target> </project>
Refinement Document
A function is an extension to a constant file, which consists of a sequence of extension operations. The order in which they appear, from top to bottom, is the order in which they are applied to the constant file by the XAK composer. A function file is validated with the schema xak.xsd before proceeding to composition. This schema guarantees that the function follows the required structure that is explained in this section. There are several types of Explicit Operators to realize extensions. A well-formed XML file is considered a function if its root element is the tag <xr:refine> and follows the next pattern.
The following fragment of file ref-build.xml is a refinement of previous constant document. First, xr:at point to the element in the document expressed by an attribute. Then, explicit xr:append adds some content to the end of this element.
<xr:refine> <xr:at select="//target[@name='test.ahead']/path/fileset"> <xr:append> <include name="bcjak2java.jar"/> </xr:append> </xr:at> </xr:refine>
Resulting document
The result of composing previous document refinement with document constant is shown below (file build.xml). Basically, a new include element is appended to the end of fileset.
<project name="FOPTools" basedir="." default="all"> <property name="project.title" value="FOP Tests"/> <target name="test.ahead" depends="initialize,require" description="Run tests on the AHEAD toolsuite"> <path id="id.path.test.ahead"> <fileset dir="ahead/build/lib"> <include name="balicomposer.jar"/> <include name="bali2jak.jar"/> <include name="bcjak2java.jar"/> </fileset> </path> <!-- more code --> </target> </project>
Operators
There are 4 explicit operations to realize Xml Refinement They are introduced below.
<xr:at select="${XPath}">: This operator points to an element in the document on which to perform operations. The element is defined by the first occurrence of the XPath expression.
<xr:append>: This operator is used inside xr:at. It appends some content at the end of the selected element. The added content is defined as a children of xr:append.
<xr:prepend>: This operator is used inside xr:at. It prepends some content at the beginning of the content of the pointed element. The added content is defined as a children of xr:prepend.
<xr:override select="${RelativeXPath}">: This operator is used inside xr:at. This operator overrides the content of the element defined by the first occurrence of the relative XPath expression (note that this XPath is relative to the one defined by xr:at). The new content is defined as a children of xr:override. The use of this operator is discouraged or at least restricted because it removes previous content, and replaces it. So, use it with caution.
Cases
An XML file can be either a constant or a function. Therefore there are 4 different composition cases that have to be considered:
function (constant) : the outcome is a constant file. function2 (function1) : the outcome is a function file. It is obtained by appending the refinements in function2 to the refinements of function1. constant (function) : AHEAD does not allow this. So, an error is raised. constant2 (constant1) : AHEAD does not allow this. So, an error is raised.
Command Line
The following are the command arguments to call the xak:
Usage xak [options] -o outputFile -c file1 file2 file3 ... Composes xml files in order ... file3(file2(file1))
Example to compose base-build.xml (constant) and ref-build.xml (function), the result is in build.xml.
xak -c base-build.xml ref-build.xml -o build.xml
Example to compose base-index.html (constant) and ref-index.html (function), the result is in index.html.
xak -c base-index.html ref-index.html -o index.html
Limitations
To our surprise, we discovered that this approach did not work well in some situations. The problem is that an XPath specification is given relative to a base document, but once the base document is refined (i.e., the addition or replacement of nodes), a path specification may no longer be correct. In reflecting on how AHEAD works, we realized that AHEAD avoids similar problems by imposing a hierarchical module structure on its features and its artifacts. This enables (i) each module to be extended in a standard way and (ii) the hiding of module details that should not be exposed to refinement.
XAK 2
Our solution was to impose a hierarchical module structure on an XML document. Instead of seeing a document as a tree rooted at node t1 in Figure 1a, we decomposed the tree into a tree of trees (e.g., trees rooted at nodes t1, t2, and t3 in Figure 1a), and then tagged each of these nodes with a xak:module attribute, so that our module abstraction of the original tree is a tree of modules (module m1 contains modules m2 and m3 in Figure 1c).
Figure 1: XAK Module hierarchy
In general, a XAK module has a unique name and contains one or more consecutive subtrees that share the module root. Each subtree may contain any number of modules. Note that the modules of an XML document reflect a natural hierarchical partitioning into semantic units that can be refined (more on this shortly). As a concrete example, Figure 2 shows an XML document that defines a bibliography. The document is partitioned into modules (see xak:module attribute) which imposes a module structure (similar to Figure 1b). Note that all modules have unique names.
<bibliography xak:artifact="myBib"> <paper xak:module="mATSRefact"> <title>Feature Refactoring ..</title> <date>06-02-21 11:30:45</date> <authors xak:module="mATSAuthors"> <author id="1"> <name>Oscar</name> </author> </authors> </paper> <paper xak:module="mXAKRef"> <!-- content collapsed --> </paper> </bibliography>
Figure 2: XAK Base doc
We define a refinement of a XAK module by an operation that is similar to method refinement in the Jak language [1]. A refinement of the XAK document of Figure 2 is shown in Figure 3 that appends a new author to the mASTAuthors module. The xak:super node is a marker that indicates the place where the original module body is to be substituted. In general, a XAK refinement document can contain any number of xak:module refinements.
<xak:refines xak:artifact="myBib"> <xak:extends xak:module="mATSAuthors"> <xak:super xak:module="mATSAuthors"/> <author id="2"> <name>Don</name> </author> </xak:extends> </xak:refines>
Figure 3: XAK Refinement
XAK is a tool that composes a base XAK document with zero or more refinements. (XAK also composes refinements into compound refinements). The result of composing the base document of Figure 2 and the refinement of Figure 3 is the document in Figure 4. Note that it is possible for a refinement to add new modules. In this example, only new content is added to an existing module. Thus, modular structure is unchanged.
<bibliography xak:artifact="myBib"> <paper xak:module="mATSRefactor"> <title>Feature Refactoring ..</title> <date>06-02-21 11:30:45</date> <authors xak:module="mATSAuthors"> <author id="1"> <name>Oscar</name> </author> <author id="2"> <name>Don</name> </author> </authors> </paper> <!-- content hidden --> </bibliography>
Figure 4: XAK Composition Result
The result of a XAK composition is a XAK document. The underlying XML document is the XAK artifact with the xak:module attributes removed. XAK does have other functionalities such as schema extensions and validation. More details are presented in [3]. Note that the tool is under development, check XAK for updates.
Download
We may release these tools open-sourcely when paper becomes published. Until then, please request to Salva Trujillo or Felipe I. Anfurrutia.
AHEAD - XAK joint distribution XAK example application
Reference
[1] O. Diaz, S. Trujillo, and F. I. Anfurrutia. Supporting production strategies as refinements of the production process. Sofware Product Line Conference (SPLC 2005), Rennes, France, 2005. SPLC. [2] D. Batory, J.N. Sarvela, and A. Rauschmayer, “Scaling Step-Wise Refinement”. IEEE TSE, June 2004. [3] F. I. Anfurrutia., O. Diaz, and S. Trujillo, On refining XML artifacts. Int. Conf. on Web Engineering (ICWE 2007), Como, Italy 2007

ATS Home Page | Onekin | XAK

Copyright © Onekin Research Group. All rights reserved.
Revised: April 30th, 2007.

Report questions/problems: Salva Trujillo | Felipe I. Anfurrutia