Earlier I posted about Synapse. My biggest concern about Synapse is that there is a lot of XML to write. To be fair, this is hardly a unique characteristic of Synapse. nspectre is primarily configured in XML – although you can write your own implementation of IConfigurationReader if you prefer something else. With the advent of .NET 3.0 XAML is a development that can’t be ignored.
So, all this XML is a great thing, right? Er, well, no. I don’t think so. In a lot of cases, we are using XML as the basis of a DSL – which means that the XML is code. And that means it gets executed. And here’s the issue – how do you test all that code? The unit testing support that is standard fare in most modern languages is absent in this space. We know what happens when you don’t unit test. And this gets even worse when the XML is generated by a tool, because in addition to the unit testing issue, it can become difficult to diff – which makes bug detection even harder. (I should just add a quick note about nspectre here. Since it generates code at runtime for use by .NET code, it is relatively straightforward to unit test the logic expressed in the configuration – which means you can write unit tests that express the intent and if you change the config in a way that breaks the tests then you know you have a problem.)
I also get the feeling that sometimes XML is being used to add a dynamic capability to static languages. If that is the case, then shouldn’t we be using languages that have the features we want?
I like flexibility as much as the next person, but I’m concerned about anything that is a block to change. And executable XML often falls into this category. Proceed with caution.