Generating the XSL

Now let's start looking at the process of generating the XSL file.

 

Normal XML rules apply. The XML generated by our ASP page must be well-formed, which means that case matters.

 

There are two approaches we could use in order to meet our goal of creating the XSL:

 

We could build a string

We could create an instance of the XML DOM, build a result tree and write out the XML as a string

Either approach is valid for our needs. The first is simpler, and may be faster, but it is a limited solution. Should we wish to revisit this application at some point in the future and extend its functionality, our options would very restricted. Furthermore, we would be limited to a linear building process, and it would be cumbersome to dynamically modify any part of the result string that had already been built. It would be difficult, for example, to add the capability of converting an attribute in the source document to an element in the result. By taking the XML DOM approach, all of the capabilities of the DOM are available to us, and we are not limited to a sequential result. Plus, it's more of an XML-purist approach to the problem.

 

So, we will need two instances of the XML DOM. The first will contain the result tree we will be building, whose XML source will ultimately become our return value, and the second instance will host the XML translation document that will drive the creation process.

 

As you're looking through the discussion of how this ASP page works, you may find it useful to refer to the end result, which is shown here as rendered in Internet Explorer 5, with the color coding and indentation provided by IE's default internal style sheet.

 

 

If you download the source code for this book and look at the interpreter.asp file in your browser, this is what you should see.

 

As is always the case when we use an ASP to generate XML, we need to set the response type:

 

 

Next we will create our required two instances of the XML DOM, and load in the interpreter.xml file (our mapping file):

 

 

Note that as this code is running server-side, we need to provide a physical path to the XML file that we are loading, which is done by using Server.MapPath. We set the async property of the interpreter file to false, as we cannot process anything until this file is completely loaded. The async property of the result tree is irrelevant.

 

Next we extract all of the <xlat> nodes from our definition tree:

 

 

Now we are ready to start populating our result tree. The first step is to add the node that identifies this XML document as a style sheet:

 

 

Then we set the root element, the stylesheet declaration, as follows:

 

 

If you refer back to the IE5 view of the XSL shown in the previous figure, you'll see that the next entry is <xsl:template match="/">, which we create as follows:

 

 

Rather than hard-coding the names of the root document and the item of the translation result (<shipments> and <shipment> in our example), we extract those tag names from the definition file. This is based on the assumption that the root element of the definition file will also be the root element of the translation result:

 

 

 

 

 

 

 

 

Note that we have created the oContainer variable, which represents the root element (shipments) of the translated result.

 

Now we need to add a line to our XSL result tree that when processed will tell the XSL to iterate through all instances of the children (shipment) of that root. The following code will create an element containing <xsl:for-each select="//shipment"> and append it to the result tree:

 

 

Next we create an entry for the contained item (that is <shipment>) and append it to the result tree:

 

 

Now we get to the real work. In this section of the code, we iterate through each of the <xlat> mapping elements. For each one, we create an element using the name attribute of the <out> element, and an <xsl:value-of> from the select attribute from the <in> element. These items are added to the result tree.

 

An example of one of these would be:

 

 

 

Finally, we need to add the apply-templates node:

 

 

We have now completely built our result tree, and we return it to the calling application (which could be a browser, a script, an XML file, etc):