Can we declare programming in Xml to be dead yet?

While I certainly think XML is dying as the only configuration mechanism of a framework, I still think it’s a valuable option, especially for doing overriding configuration details at deployment time.

Completely agree and it’s the most liberating thing ever. All of my configuratiion, even my connectionStrings, are hard-coded. The advantages of easy testability, refactoring capability, and intellisense blows away any argument for XML.

“especially for doing overriding configuration details at deployment time.”

You can do this with a configuration interface and an IoC.

@Jim Greco,

You’re going a little bit farther than I would. We still keep NHibernate properties, connection strings, and file paths in config files. It’s the StructureMap.config file though.

You need to make a distinction between admin & developer configuration. They go to different places.
Admin conf in xml or whatever is a good & necessary thing.

How much of the pain is due to the amount of crap that has to go into XML that makes the hand coding painful at best (namespaces, angle brackets, closing tags, etc)?

If you had perfect intellisense around a more compact syntax (JSON) and an easy way to know valid vs invalid, would it be interesting to express your intent in a non-code text file? (you could argue that you’ve already got this in C# initialization syntax, but is there benefit in storing this in something other than a compiled assembly?)

How would one build tooling on top of the fluent nhibernate dsl or the structure map registry dsl? (I ask because I’m not familiar with either (two more todo’s added to the queue)). The nice thing about xaml / xml, etc is that tooling can operate on that pretty easily, as opposed to using codegen style transformation between the tooling representation and a c# seriialization format.

How do you change configuration for different environments with code over xml? Do you alter code as part of a pre-build event?

The pendulum is definitely swinging away from XML, and for good reason. Will it swing too far, and is that possible? That’s the interesting question.

I wonder how much of this (movement away from XML towards fluent-config stuff in code) is driven by important software design goals and how much is simply driven by the (relatively) poor tooling support for XML provided by many popular IDEs.

For example, let’s assume for a moment that invoking RENAME of a class in the IDE cascaded the rename down into the XML that referenced it…would we *still* find XML config to be unacceptable–?

This reminds me of the legions of (.NET) developers who similarly ‘hated and despised’ javascript largely due to the poor tooling support for it in Visual Studio rather than as the result of an actual software design decision about the value of javascript in improving their solutions.

I wonder how much of the move away from XML towards config-in-code is really based on tooling limitations vs. design / requirements needs…

@Steve,

Think readability and expressiveness too. Plus, even if the tooling got better to give you class, property, and method level intellisense in Xml editing like you’d need to make hbm xml files efficient, think how ugly that ends up looking.

Your offhand dis of XAML put me in a defensive mode at first, but when I thought about it I realized it’s WPF I’m really a fan of, not XAML per se. I found XAML less cumbersome than traditional WinForms development, but it is cumbersome for the same reasons other forms of XML is cumbersome (although I’d say it’s level of Intellisense support is better than most).

I didn’t miss the boat on some cool alternative to WPF did I? Or a cool alternative to using XAML with WPF? Bypassing XAML is certainly possible, but I’m not sure how easy it would be to make it concise enough to be readable.

@Mike,

The problem with Xml is the crazy ways we’ve used it far and beyond its original intention.

Personally, I run very hot and cold on WPF. I love the underlying technology, but I’m iffy on Xaml and I think using WPF programatically is a near nightmare.

I’ve had some luck using C# DSL’s on top of WPF and I still think the WPF + IronRuby combo could be killer. The raw “push button” API for WPF sucks hard because it’s optimized for Xaml rather than developer usability.

I was thinking about it a little more and I wonder if it’s fair to go after XAML without going after HTML too. Do you perceive a fundamental difference between the idea of laying out the UI in XAML for a client app vs laying it out in HTML for a web app?

@Mike,

Not really, and I vastly prefer the markup approach or WPF Xaml or Html/CSS versus the WinForms way. I do wish they’d made WPF’s Xaml more of a markup DSL instead of taking the serialization format shortcut. I think the way they implemented WPF’s XAML sacrifices some usability. I’m also willing to concede that maybe I’ve just never gotten completely used to Xaml in WPF.

Fluent all the way for me.

We had too much pain with oversized Windsor xml config files. Now they’re all fluently loaded in one small class. Much more manageable. Plus it’s all strongly typed, so no more runtime errors due to something missing from the xml config. If anything changes we get a compile time error which is much more preferable.

Fluent NHibernate is the next thing we’re looking at to make our mapping files a little more robust.

Xml has it’s place, but in terms of IoC and NHibernate I don’t know why you’d want to be able to change the config once deployed. May as well just have it compiled to start with.

“How do you change configuration for different environments with code over xml? Do you alter code as part of a pre-build event?”

Never.

It’s a simple interface (“IConfig”) with different implementations for each environment (each developer has one like “GrecoConfig” for their environments, “QAConfig”, “StageConfig”, “ProductionConfig”, etc.) .

StructureMap injects the right implementation at run-time. A system variable controls which one to inject. One-time setup and you never worry about it again.

Now everything is refactorable;
Testable;
Properties can be complex (i.e., I can have NumDays be an integer instead of a string that is parsed into an integer, I can have a ConnectionStrings object vs. just a string, etc.);
Inheritance (qa, stage, and production use the same sql box, why repeat that 3 times?);
Settings won’t allow for compilation if they aren’t there (what happens when you forget that new key/value pair that you added to the development xml config but not the production xml config)

I see no reason any of this has to be in XML. If your deployment system sucks, work on it so deploying a stable build to any environment is a snap.

This should be expressed as a T-Shirt: “Say NO to XML programming” or something like that. I think I might get some interested…any takers over here?

Interesting post Jeremy, and I’m looking forward to meeting you at the NDC this summer. I’m presenting on the MVVM pattern + Silverlight 3 business applications. So as you probably can guess by my choice of topics I’m a big XAML fan.

But you got some interesting points, and I largely agree with you. I always prefer fluent DSL’s for config (IoC, Hibernate) over the error prone XML alternative. However, for UI I think the declarative nature of XAML works well – both from a tooling perspective and it’s also a good format for people with a web background. But I think your point about the WPF API being build for XAML, and not for developer friendliness is spot on. I often find my self struggling on how to achieve something using procedural code over XAML, and the code tends to be big, verbose and hard to follow with lots of untyped strings and object casting.

It will be interesting to see if we (as the community) can come up with some other cool alternative approaches to WPF using some UI DSL + the new XAML/BAML Reader and Writer being introduced in WPF 4.0.

Cheers,
Jonas Follesø

I find the use of XML in so called build scripts to be a source of particular frustration. XML should only be used for declarative data – in other words, configuration. Referring to an XML file as a “script” indicates a major problem. Only the most trivial builds can be described using declarative syntax alone. Builds of any complexity cause the configuration to quickly become horribly difficult to maintain, and you end up doing much of it in code anyway.

I think XML has its use. Like you, I’m skeptical of using it as a configuration file, as it can be quite verbose.

It is quite useful for providing common format for interchange of data. But I think the days of it being considered a “human readable” format are over. With schemas, namespaces, etc… anything but the most simple XML file is far from readable without a good XML editor.

@Jim Greco
Your design seems much too complicated and it stems from not using XML for what it is meant for which is a portable format for the interchange of data and *not* code. So XML is perfectly fine for storing data such as connection strings but a disaster waiting to happen for coding.

An interface and an multiple implementation is too complicated? Do you find unit testing hard too?

and an multiple = with multiple

5 years ago when I said all this XML config crap is for the birds I was nailed too the wall….

Anyway though, I’m glad to see this post, it helps me feel vindicated for times in the past where this opinion was very very unpopular in certain circles.

I would argue that programming in XML is alive and well – whether we like it or not. Look at XAML, WF, MsBuild/NAnt, and many other technologies. You might get a pretty design surface over them (which is often more pain in anything beyond demoware), but you’re still programming in XML. The fluent APIs in Windsor, StructureMap, Fluent NH, and others are much better than their XML counterparts. Hopefully they continue to draw interest. At the heart of it, XML is a reasonable data format (not perfect, but reasonable), but XML for programming is a PITA. One of my big worries for the next five years… Are DSLs the next XML? A well-crafted DSL can be amazingly productive, but equally so is a well-crafted XML data document. Are we going to throw DSLs at every problem like we did XML and wind up in a similar conundrum in five years time, except with us bemoaning the inappropriate use of DSLs?

Jeremy / James

A very pleasing and topical post for me. The problems I had with Spring configuration in my last project were unbelieveable and its the major lesson learned. The fluent terminology is new on me (with the exception of Fluent NHibernate) but one that I’m looking out for more and more now that I understand the major drive for it.
Instinctively, I looked at the other tools that I produce a lot of XML files for and NAnt is the one that jumps out at me. I’ve used 2 completely unrelated editor tools in the past. These help me with XML syntax, but not with testability, etc. Excuse the ignorance, but does anyone know of any fluent NAnt movement?

@Jim Greco

To answer both your questions. No and no. My *point* is that based on what you were trying to accomplish your code could be simplified to a much simpler design. You have greatly overcomplicated a simple task.

o.s, isn’t it really just a different way to look at the same problem? Where I previously worked we had config files 100s of lines long, considering we had one for each stage of development (at least one dev, QA, Stage, Production), that’s a lot of code sitting in XML that is difficult to verify.

Using Jim’s method, he has the same number of files, but due to them implementing an Interface, his code won’t compile if a setting is missing. You can’t say the same for Xml Configuration Files.

Xml Config Files do let you easily change things on the fly, but I’m not sure that’s necessarily a good thing. Granted, using Castle Windsor, I’m sure you could do the same thing with Jim’s method as well.

Done right, I think an IConfig method isn’t that complicated at all.

“Can we declare programming in Xml to be dead yet?”

According to the SharePoint team at Microsoft: HELL NO!

It will depend with the persons or company who’ll be using it.

XML provides a syntax that can be easily parsed and easily manipulated — that is its great strength (think in terms of decorated s-expressions). Using it as a common interchange format makes perfect sense. At the same time, exactly because of its syntactic regularity, placing a syntactic skin on top of it is pretty easy to do — and you really don’t want to be looking at reams of “code in XML” (or anything else, for that matter) in its native form.