DVSL is a fairly small, little known, product associated with the Velocity project over at Apache which takes the best part of : , and replaces the verbose and frustrating scripting of XSLT with a java-based template language instead.
What’s Wrong With XSLT?
The biggest problem with XSLT is the problem I have with custom-written domain-specific languages (DSL) in general (Make, XSLT, Maven’s POM, etc, etc): They lack all the features of a heavy weight modern language.
As soon as you want to go out of the box defined by the language you have to resort to hacks like writing pre-processing and post-processing scripts in other languages, extensions in a particular implementation of the interpreter, etc.
Domain specific languages written within an existing language (take JMock or SConstruct) mean you have the power of the DSL as well as the resources of the containing language (in this case Java and Python). When you encounter a situation the tool designer did not consider important, you don’t have to write a custom plugin, you just write plain old code.
The second problem with XSLT is verbosity. Since all of XSLT is written in XML, doing things like inserting a value into the output text or defining a variable require a lof of typing.
Also, although this is arguable a stylistic issue, XSLT often requires recursion where a loop is the more appropriate mechanism.
Although XSLT does support non-XML output, it isn’t particularly good at it. This is particularly true when that text output contains large amounts of XML special characters like < and & .
What is DVSL?
DVSL uses XPATH to select nodes within the source XML document like XSLT, but once you have matched a node-set DVSL applies the Velocity template language.
As a template language written in java, velocity has access to the java language in general and a fairly wide set of tools targeted towards text/html/xml generation in specific. Because it’s a template language, DVSL also makes it easy to insert values into the output text. Finally, because it’s not written in XML, text output is much more like a perl block print than something like XSLT.
For example, lets take the following input:
<?xml version="1.0" encoding="ISO-8859-1"?> <contacts> <contact type="friend"> <name>Bob Ripley</name> <age>45</age> <e-mail>email@example.com</e-mail> </contact> <contact type="business"> <name>Shirley Hannely</name> <age>24</age> </contact> <contact type="business"> <name>Steve Gates</name> <age>50</age> <phone>555-5555</phone> </contact> </contacts>
Generating a text file from this is fairly straight forward:
#match("contacts") My Contacts This is an automatically generated list of my contacts. Friends $context.applyTemplates("contact[@type='friend']") Business Associates $context.applyTemplates("contact[@type='business']") End of document #end #match("contact") Name: $node.selectSingleNode("name").value() $context.applyTemplates("*") #end #match("age") Age: $node.value() #end #match("e-mail") E-mail: $node.value() #end #match("phone") Phone: $node.value() #end
Issues With DVSL
(NOTE: correction. DVSL can read from multiple input documents despite what I said earlier). There are a number of other things it does not do well however which will probably result in a new article.
The maturity is somewhat lacking here. The documentation is, to be kind, minimalistic and there are a number of features conspicuously missing such as lack of sorting int the applyTemplates results.
As with velocity itself, the product is also very oriented towards a web environment. When I wanted to run DVSL from the command line I had to write my own wrapper script for setting up the classpath and so forth.
Finally, there is a lot of untapped potential here. The XPath implementation used by DVSL is actually jaxen, an awesome tool for navigating collections of s using XPATH. This presents the attractive possibility that one could use DVSL to produce a report from an arbitrary java object tree.