WhySlax

Why Did We Make SLAX?

Well....

I have worked with XSLT for over ten years, as part of my work for Juniper Networks. Beginning in 2001, we made an XML API for our line of routers so that any CLI command could also be available as an XML RPC, with the response received in XML. This work was the foundation for the IETF NETCONF protocol (RFC6241) (see also RFC6244).

Internally, we used this API with XSLT to make our Junoscope network management platform, and were happy working with XSLT using multiple XSLT implementations.

In the 2005-2006 timeframe, we started developing on-box script capabilities using XSLT. I like the niche and properties of XSLT, but the syntax makes development and maintenance problematic. First class constructs are buried in attributes, with unreadable encodings. Customers objections were fairly strong, and they asked for a more perl-like syntax. SLAX was our answer.

SLAX simplifies the syntax of XSLT, making an encoding that makes scripts more readable, maintainable, and helps the reader to see what's going on. XML escaping is replaced by unix/perl/c-style escaping. Control elements like xsl:if are replaced with the familiar "if" statement. Minor details are more transparent.

The majority of our scripts are simple, following the pattern:

if (find/something/bad) {
    call error($message = "found something bad");
}

The integration of XPath into familiar control statements make the script writers job fairly trivial.

At the same time, using XSLT constrains our scripting environment and limits what scripts can and cannot do. We do not need to worry about system access, processes, connections, sockets, or other features that are easily available in perl or other scripting languages. The scripts emit XML that instructs our environment on what actions to take, so those actions can be controlled.

So SLAX meets our needs; I hope making this an open source projects allows it to be useful to a broader community.