According to Ant’s webpage:

“Ant is a Java-based build tool. In theory, it is kind of like Make, without Make’s wrinkles and with the full portability of pure Java code.”

Sounds nice, isn’t it? But XML design problems make Ant nearly unusable which this post becomes kind of a rant…

The Current Situation

It started some time ago when I tried to use Ant for building a book. So I’ve looked into the documentation and saw Ant uses XML for their build files. “Great!”, I thought, “I start my XML editor and I’m ready to go!”

A good XML user should use a Schema whenever possible. So I searched for some DTD, RNG, or W3C Schema which my XML editor can use. However, I found this notice from the FAQ (cited from this page):

• It doesn’t know about required attributes. Only manual tweaking of this file can help here.
• It is not complete – if you add new tasks via <taskdef> it won’t know about it. See this page by Michel Casabianca for a solution to this problem. Note that the DTD you can download at this page is based on Ant 0.3.1.
• It may even be an invalid DTD. As Ant allows tasks writers to define arbitrary elements, name collisions will happen quite frequently – if your version of Ant contains the optional <test> and <junit> tasks, there are two XML elements named test (the task and the nested child element of <junit>) with different attribute lists. This problem cannot be solved; DTDs don’t give a syntax rich enough to support this.

So with a XML editor on one hand, and with no schema on the other, Ant left me in the dark.

The Problem

So why then use XML? Why not use another syntax? The reason to use XML is not only it is easy to parse its syntax, it is also for its ability to validate your XML file. I don’t know the decisions that drove the Ant team to XML. However, it seems to me, Ant uses XML only halfhearted. This wouldn’t be bad per se. The bad thing is, that it circumvents XML good practices!

So what’s exactly my problem with Ant? I have these:

1. A XML Structure Without Schema is Useless
   Ok, to be fair, not every XML structure needs a Schema. Very easy ones does not probably need one. However, if your structure becomes a bit more complicated, it is very important to have a Schema. It is even more important when your structure are used by other people and becomes widespread. How can people know if something is wrong when there is no Schema? Impossible! They have to run Ant every time or look into the documentation.
2. Redefining the XML Structure is Breaking XML
   The taskdef is probably one of the worst elements in Ant. I have never seen this concept in any other XML structure before. Even when you have a Schema, it circumvents the structure by introducing new elements just “accidentally”. This makes the whole concept of your validation useless.
3. No Official Schema
   Why using such “complicated” XML when no Schema is available? This seems not very userfriendly to offer XML without an underlying fundament.
4. Why XML?
   Although you can tell me a “fan” of XML, I don’t think it is useful in every case. There are certainly reasons why the Ant team chooses XML over another syntax. However, then it should take into account of a schema too. I’m not fully convinced of the advantages of XML as a building tool (with the lack of a good schema.)

A Possible Solution

To improve the situation for XML users, I think the following should be interesting:

1. Provide a RELAX NG Schema (RNG)
   In my humble opinion, this is the absolute minimum to work efficiently with Ant’s XML structure. The RNG should contain the core elements of Ant’s structure. Weather the RNG is liberal enough to allow further elements from other namespaces or not, is a matter of design.
   If your XML editor does not support RNG, there should be a DTD or W3C Schema available. However, the semantic power is not always the same with these schema languages.
2. Use The Expressive Power of RELAX NG
   Ant’s XML structure contains sometimes conditions like: “Use only one attribute from this list.” This condition can be expressed with RNG’s choice element. The advantage of this approach: your XML editor helps you in creating valid XML during your writing.
3. Get Rid of taskdef (And The Like)
   This was not only totally unexpected, it is a nightmare for every XML editor (as described above). No Schema should be fooled with this “broken by design” method. There are other methods to introduce further elements, be it in a separate namespace or, for example, with an element usetask with an attribute name. This might be not as short as taskdef, but it is much more safer.
4. Document The RELAX NG Schema
   With documenting I mean not only a decent HTML page, but also some helpful tips inside the RELAX NG schema too. Modern XML editors which support annotations, can show a small tool tip to provide  users with helpful information. This is very useful as the user does not have to find the information-the information comes automatically through the XML editor.
   Another advantage: You can extract the annotation to create a separate HTML page, for example.
5. Provide a Conversation Tool
   You can only make these “radical” steps, when there is a good conversion tool from major version n to n+1 available. This could be a XSLT stylesheet that converts the taskdef into something more useful.
6. Offer a “Compact Syntax”
   RELAX NG schemas can be written in two forms: as XML and as a compact syntax. This is very, very useful, as it allows users to take part when they don’t like XML. It is also possible to convert the two without problems. If you still need the validation structure, convert it into XML, validate it and you are done.

Schema design is not as easy as it looks. There are lots of problems that you only see after some time. That’s probably the reason, why the World Wide Web Consortium needs some time to declare a specification a W3C Recommendation.

XML can be good. But it can also be broken when it is badly designed.