Domain Specific Languages and XML

There has been a lot of thinking about the use of Domain Specific Languages to solve a particular problem.
This is even a major feature of Visual Studio 2005 and above.

Typically these are things like Ruby on Rails which is essentially a DSL for creating dynamic websites quickly.

However there is a much simpler solution.
State your problem in XML and use xslt to generate the solution.
If done carefully you can eliminate a lot of easy to write, but easy to get wrong code.

This is really what Kathleen Dollard has been talking about in her Code Generation in .net book.

Here is an example that almost all applications have to deal with:

How much work is it to add another maintenance screen to the system?
or even
How much work is it to add one field to one maintenance screen?

If you get the principle working for one screen you can add another by adding a few lines to an xml document and regenerating the script.

Code Generation of Stored Procedures with examples

This is an article on code generation of stored procedures with examples.


Here is the main outline of the stored procedure generation template

<xsl:stylesheet version=”1.0″ xmlns:xsl=””&gt;
<xsl:output method=”text” standalone=”yes”>
<xsl:preserve-space elements=”row”>
<xsl:template match=”/”>





This is how to construct the insert body.

INSERT INTO <xsl:value-of select=”$name”> (<xsl:for-each select=”columns/row”>
<xsl:value-of select=”@COLUMN_NAME”>
<xsl:if test=”position() != last()”>, </xsl:if>
VALUES (<xsl:for-each select=”columns/row”>@<xsl:value-of select=”@COLUMN_NAME”>
<xsl:if test=”position() != last()”>, </xsl:if>


With this as a stub it will be easy to create the script. 

Codegen at Runtime

Codegen is usually used at build time to produce source code for an application.
However I have recently found a use for it at runtime (although infrequently).

The application that I work on has an archive process that takes the older data away to a secondary database. Periodically a new archive database is created.

We used to use dynamic sql within a stored procedure to move the data from the live to the archive. Strings were constructed within a stored procedure and executed. This turned out to be too slow.

I replaced the dyamic sql with a set of stored procedures that were regenerated at archive creation time using XSLT. This is exactly the same technique as traditional code generation, but  has provided a massive speed increase (3X to 7X improvements have been seen).


Code Generation In .NET

This is an important site for an important topic.

Years ago I was involved on a project that was seriously delayed due to the failure of a CASE tool. The project had all of the design completely modelled – it was just that the CASE tool that was suposed to split out the code did not work and the company making it went under.

Code Generation seems to fulfill the promise that CASE tools had been making at the end of the 80’s. Kathleen Dollards approach is entirely feasable. She uses XSLT to generate code from metadata that is either manually created or extracted from for example a database. This is ideal for the middle tier and data access layers which are typically mechanical.