That guy Loren Halvorson has relased XmlPreprocess tool for preprocessing XML files, e.g. config files in .NET. It allows to perform the following tricks:
<configuration>
<system.web>
<!-- ifdef ${production} -->
<!-- <compilation defaultLanguage="c#" debug="false"/> -->
<!-- else -->
<compilation defaultLanguage="c#" debug="true"/>
<!-- endif -->
</system.web>
</configuration>
As you can see he decided to embed preprocessing instructions into comments. Too bad. Why? First of all because comments are for comments and reusing a tool for a purpose it wasn't designed for is always bad idea. Second - surprise! XML has native syntax for expressing processing instructions - it's called processing instructions. And third - a much better way (at least comparatively to using comments and PIs) of mixing data with different meaning in XML is called XML namespaces.
Now back to our mundane world. Unfortunately in .NET one cannot embed elements in a proprietary namespace or even plain XML processing instructions into standard sections of config files! So using such poor hacks as embedding data into comments is the only workaround. Too bad. That's just another example of how violating a basic principle called "Allow All XML Syntax" makes your customers to invent poor hacks when they only want to extend your product.
If one is to use this XmlPreprocess tool to preprocess web.config for production configuration, what stops the person to preprocess it for development or any other environment. Then we don't have to worry about the fact that .NET doesn't "Allow All XML Syntax", similar to what Jonathan does with XSLT, but maybe using processing instructions, I don't know.
I think it's pure laziness - which may be a quality that is desired in some cases? Of course, I'm not saying this about the person who wrote the tool; he's obviously not lazy spending all that time writing a tool to preprocess a configuration file. I'm not being sarcastic by the way.
To be fair, my XSLT-based solution below does not allow what comment-based solutions such as XmlPreprocessor offers, which is that the unprocessed file is usable as-is by the target application. I can understand that this could be a desirable property in some situations.
Cheers,
--Jonathan
That's funny, I thought you were going to mention XSLT. For our configuration files I've used an XSLT-based approach based on the "literal result element as stylesheet" syntax. It looks like this :
<configuration xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<system.web>
<xsl:choose>
<xsl:when test="$production">
<compilation defaultLanguage="c#" debug="false"/>
</xsl:when>
<xsl:otherwise>
<compilation defaultLanguage="c#" debug="true"/>
</xsl:otherwise>
</xsl:when>
</system.web>
</configuration>
(or even more concisely with an xsl:attribute construct !).
Actually I use a preprocessing pass to build a real stylesheet because the literal stylesheet syntax does not allow for external parameters, but that's the basic idea. Thanks to XSLT's XML syntax this is a breeze to do in an XmlReader.
Totally agree with you about XML syntax enabling a lot of exciting scenarios. As another example, I recently implemented custom XSLT-like elements for our stylesheets by preprocessing them with a "preprocessor" stylesheet that replaced the custom elements with actual XSLT code.
Cheers,
--Jonathan
PS: for an XML/XSLT oriented blog, you really need to teach your blog software to respect < and > in comments... :)
Still thinking what to answer, but XPS syntax is definitely much better :)
So, are you saying my XPS idea was good, after all? :)