The Truth About XML vs. Scripting

Programmers are really language designers – creating layers of abstraction between their general purpose programming language and the domain problems they need to solve to allow their programs to be more elegant.

Have you ever written a custom tag to abstract the rendering of a paged table list? How about a tag or CFC method that hides the SQL to perform simple access to a table? If so, then congratulations – you’re a language designer! You have added a declarative layer to your code that allows you to use a more abstract language that you designed for rendering table lists or for doing simple SQL queries. (Declarative simply means that you are telling the computer what you want – not how to do it. SQL and RegEx are two well known general purpose declarative languages, but any time you create a CFC or a custom tag (or a config file) you are creating your own little language – or as they are called, a “Domain Specific Language”. DSLs can be either horizontal – data access, validation, workflow, etc. or vertical – insurance, stock trading, etc.)

Once you start looking at programming as the art of writing layers of language to allow the clearer expression of intent, you start to get a different perspective because things that used to look very different now all look to be very similar.

Lets say that our goal is to design a very simple language to allow for the returning of a list of users from a database (I’m going to make the example trivial so we can focus on the concepts – not the problem domain which can actually get quite complex once you start to support joins and havings and all of the rest). First step might be to create a custom tag (or hopefully these days a data access object written as a CFC – lets call it UserDAO). Lets add a method with a signature of getUsers(Filter: string, Orderby: string) which allows us to get a subset of the users in the database using some kind of filter and to control the order in which they return. So, while it may seem a stretch for such a simple case, I have actually created a (very) small domain specific language for describing the filtering and ordering of users.

We could even describe the abstract syntax of the language:

getUsers ::= [Filter: string] [Orderby: string]

Now usually we wouldn’t think about this, but the next choice is the concrete syntax to use to write this “language” with. By default we all use in-language DSLs just writing the “language” using method calls with either ColdFusion or CF Script, but that is only one possible notation. It would be quite possible to create an XML implementation of the abstract syntax (which would look quite like calling a ColdFusion custom tag). It might look something like:

We could even create a custom concrete syntax for describing the same intent. Perhaps something like:

getUsers: “LastName = ‘b%’”: “FirstName”

That concrete syntax is using colons for attribute delimiters and new lines for tag delimiters, making the parsing of it fairly straightforward.

The important distinction to be made is between the process of language design and the selection of a concrete syntax for describing it. I often heard it said that a downside of XML config files is the extra tags you have to learn – this just isn’t true. Assuming that an XML document has been well designed, the tags you have to learn are just the abstract syntax for a domain specific language that allows you to more elegantly express the intent of a concept than writing it natively in ColdFusion. Now, you don’t need XML for that. You could just write a set of method calls against methods that implemented the same grammar, but if you want to use those abstractions, you’re going to have to learn the concepts – whether they are expressed as an XML schema (tags) or an in-language extension (a set of method signatures).

Choosing a Concrete Syntax
The question then is how do you choose a concrete syntax? Firstly, you have to know your options. The first option is an in-language extension. In ColdFusion the options for this are UDFs, custom tags and CFCs. The second option is XML. The third option is a custom textual syntax and the fourth option is a non-textual representation – anything from a spreadsheet or data table to a graphical interface.

Briefly, special cases are sometimes best served by a data table (think state machines or some rules driven systems) or a graphical interface (for describing layout or describing things like object models). For other cases, the first choice is between in-language and external DSLs. In-language DSLs are simple and flexible. You can mix your DSL with native language elements so you can easily use loops and conditionals without having to manually add them to your XML DSL (fusebox!). On the other hand, you don’t get any of the free grammatical validation with an in language DSL, and by providing flexibility people often misuse the language, adding imperative coding in the wrong places – flexibility is both a benefit and a curse!

If you do decide to create an external DSL, you’ll probably start with XML because all of the grammatical validation comes for free. I actually prefer custom textual syntaxes to XML for anything I’m going to be using a lot. For example if I want to describe an object and it’s attributes I’d prefer:

Article: extends BaseObject
Title: text(100): required
HTML: ntext: optional

to:

However, to do this requires writing your own parsers, which right now is still a bit of a pain (although expect advances in Language Oriented Programming to simplify this somewhat in 2007/2008).

So, when you’re solving a problem, start by working up an abstract syntax, and then select one or more concrete syntaxes to support (no reason why you can’t support diagrams, XML AND in-language scripting if you want to). As per my article in GAQU2, an in-language approach using base classes to evolve your abstract grammar is often the simplest approach, although I’m working up a system for exernal DSLs that will make the creation and editing of external DSLs as easy as modifying the syntax of a set of method calls.