Slashdot Mirror
Ant - The Definitive Guide
As a long time Ant user, I have written many Ant build scripts, automating my builds and speeding up the overall development cycle, mostly relying on its excellent online documentation. As a Java developer, I have admired its simple and intuitive interface and the modular design. So on getting Ant: The Definitive Guide in my hands I wasn't expecting a whole lot new to learn, and thought of using it only as a reference book.
After having the book on my desk for more than a month, though, and occasionally flipping through its pages whenever I would otherwise have consulted the online documentation, I must say that I had been missing out on some very important things: tasks like ftp and war deployment that I was simply not aware of and had never felt the need to look up, but could very well use. The other interesting thing I noticed was that my build scripts became smaller, more modular and easier to read.
Like most books in the The Definitive Guide series, Ant The Definitive Guide assumes a certain level of familiarity with underlying technologies such as Java and XML and focuses on providing complete, reference like details of Ant features and tasks. These description are generously supplemented with examples and code fragments.
But so is the the online documentation for Ant! Will someone gain additional insight in using Ant, or be able to work faster, or make better use of Ant capabilities, by consulting this book, instead of the online documentation for a particular Ant task? To find the answer, I randomly picked two topics -- filesets, an important and oft-used Ant datatype, and javac, a core Ant task -- and compared their online description with the one in the book. Here is what I found.
Besides the datatype definition, explanation of various attributes, sub-elements, and the examples, the book also covers how to specify conditional inclusion or exclusion of certain filename patterns when a property is set (or unset). Though this can be inferred from online documentation by a determined user, this particular use is far from obvious. The coverage in the book also talks about the relationship of the fileset datatype with the javac task, pointing out that the fileset attribute dir is equivalent of javac attribute srcdir, as attribute dir will be confusing in javac: is it referring to source directory or destination directory. This is the kind of insight that really helps a user.
The treatment of the javac task in the book is not much different from the one in the online documentation. Both have almost the same material, though the information in the book is better organized for new users. On the other hand, I found the online documentation to be more complete, especially with respect to the compiler specific options and behavior idiosyncrasies.
Here is a rundown on what the book covers: Chapter 1, Getting Started is a quick primer on Ant, with sufficient details for a new user to start using Ant for very simple build tasks. Chapter 2, Using Properties and Types introduces the building block tasks and datatypes, such as property, condition, fileset, path like structures, selectors and so on, used in other Ant tasks. Chapter 3, Building Java Code covers the tasks and activities around compiling Java source files (ie; javac), organizing the build steps in various targets within a single build scripts and/or across multiple scripts, generating documentation using javadoc and creating distribution jars and zip files. The rest of the chapters are devoted to tasks for specific purposes, such as launching external programs (Chapter 7, Executing External Programs), copying files and manipulating directories either on the same machine or over the network (Chapter 4, Deploying Builds), running JUnit tests (Chapter 5, Testing Builds with JUnit) and so on. There are also separate chapters covering interaction of Ant with XML and XDoclet (Chapter 9, XML and XDoclet) and with Eclipse (Chapter 11, Integrating Ant with Eclipse). The last chapter, Chapter 12, Extending Ant, talks about extending Ant by doing things like adding your own tasks, creating custom filters, writing your own build listeners and loggers etc. This chapter also has a small section on how to embed a script written in one of the supported scripting languages within an Ant script.
As you can see from this outline, the book covers almost everything that is to know about Ant and other related software.
So, what is not so good about this book? Well, I didn't find anything wrong with the topics which are actually covered by the book. Of course, there are additional things that I would have liked to see in the book: (a) A good sample Ant script which could be used as the starting point for most small to medium-sized projects; (b) A more thorough explanation of how dependencies among targets determine the execution sequence and how this fits in with explicit invocation of targets; and (c) pictures to illustrate some of the concepts such as life cycle of an Ant task, selection of files in a fileset and the dependency tree of targets.
Overall, I found the book to be comprehensive, well organized, easy to read and good value for money.
You can purchase Ant: The Definitive Guide from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
I like how the make file are XML based. With other makefiles, you get stuck if your tab has a space in it :/
Good review though!
So, what could a book say that is already not available online?"
Nothing, you have to read it.
Sorry, i just had to...
for free wallpapers, visit Sargosis.com
So, what is not so good about this book?...Of course, there are additional things that I would have liked to see in the book: (c) pictures to illustrate some of the concepts such as life cycle of an Ant
Here ya go:
Life Cycle
Is there a graphical application to help generate ant build scripts? Maybe it will help those starting out in Java get familiar with ANT. A lot of new programmers I talk to are afraid to use ANT because it looks complicated.
Take the Dragon Survey
Use Maven. :)
This book is cheaper at bookpool.com ($22.50) than at bn.com ($27.96 bn price/$25.16 member price). Get it there and save a few $$.
GOBACK.
What kind of name is Kumar? What is that like 5 o's or 2 u's?
I have worked on a couple products which have used ant as the build system. These were released a few years ago and I think the version was ant 1.3. The online doc at the time ~2002 was mediocre. I think it has gotten better now, but the book still covers all the basic features you will ever need and decreased our old make full build time from 30-40 minutes to about 10 with ant on the same hardware, as well as making it much easier to make changes and add new steps. When making minor changes ant will recompile and determine dependencies in just a few seconds where our make system would still take 5-10 minutes just for incremental change. Granted our make system could have been optimized, ant was a good excuse to start over. I have a paper copy, but do also use safari to search through the text. This gives you the best of being online and having the book.
Inheriting fully-formed Ant scripts for a big build and then having to add in your new units is not only daunting, but confusing as well.
But its just like makefiles... stop being scared, figure it out, and then welcome to the world of easy-builds.
(or you could just add your object files to the jars by hand...)
In the future, I would want to not be isolated from my friends in the Space Station.
Is there anything out there that is (a) easily deployable (nothing turns off a prospective user than being told to download and install a complicated build system that depends on $LANGUAGE_OF_THE_MOMENT), (b) suitably flexible that I can customise it to work with all my little build tools, and (c) sufficiently elegant that I won't want to vomit looking at my build scripts six months later?
So far, the only thing I've found that works at all is traditional make. Which, I'm afraid, sucks. Makefiles scale very badly (recursive make. Eeeaah), don't handle disparate rulesets well (I want to build these C files with this rule and these with this other rule... oh, wait, I can't), and the dependency handling is practically nonexistent (you can fake to a certain extent with .d files, but that all falls apart as soon as you need to depend on dynamically made files).
A case in point: I maintain the ACK, a portable compiler toolchain that's about 20 years old. The build system is an intricate network is shell scripts and recursive makefiles. It works, but it's largely incomprehensible, very slow, doesn't handle incremental rebuilds, and is going to be a maintenance nightmare should we ever need to do any major revamps. I'd love to replace it; I've gone out actively looking for something better --- and I've failed.
Any suggestions?
This has been a public service rant by a stressed build technician.
I know the moderators will hit me for this, but from the sys admins point of view - ant is evil!
/etc !!!
/etc is a very good example of what is wrong with plain text files - no single program or API could ever handle the range of formats of files there! Incidentally - XML IS plain text.
Ant isn't for sys admins.
It is simply another build program to learn. The C and C++ stuff for the kernel is "make" - now I have to learn "ant" for Java programs.
As Java isn't used (yet!) for kernel stuff, what is the problem?
I am not against learning new things, but where some people see XML as a good thing - I think it sucks! I despise any time I see a config file that is XML. XML is for the "parsing impaired" - use a plain text file like everything in
Sorry, wrong way around. XML was designed specifically from the start to be parser-friendly. There are very simple APIs which handle any XML file such as SAX.
If folk want something better than make, but don't want something so Java-centric. Have a look at SCons.
:) (Yes, SCons handles Java as well as C or C++).
The software, as well as the confuguration files, are actually Python. But, you won't notice until your build requirements get quite complex.
Scons keeps track of dependencies using MD5sums on the tail nodes. This takes up a bit more processing time, but more than makes up for it with highly-parallelizable builds (SCons + distcc totally rocks), guaranteed correct builds (never do 'make clean' again!).
We've just converted a project from Make to SCons, and it's cut our build time by about 40%. I might even be able to convince our java guys to try it out, too
'Not sure why you woulda gotten modded down had you just put in the first two sentences because you have a valid point. OTOH, it might be more relevant to a discussion of Ant vs Make than a discussion of a book review on Ant.
I.e.: I see your point (see below), but what does that have to do with this book?
I've been "bilingual" for awhile and that fact landed me in a mixed C++/Java project last year. Some consultants had built some of the java stuff using Ant and it just made things confusing and unnecessarily complex to have builds using both Make and Ant. Eventually all of the build.xml files were converted to makefiles and we were homogeneous.
Mark
Oh... And I can use make and a Makefile to compile C code and the Java code of the same project.
If you understood Ant, you would know that it can do this as well.
You fail it.
After all, I am strangely colored.
besides, what's stopping you to use make should you create your own java sysadmin tools?
i don't assume that, as a sysadmin, you should have to deal with (java) software that others write, except maybe to install it.
The best thing about using make and a Makefile instead of Ant is that I don't need to read books like this.
You don't need to learn make from books because you already know it, and if you knew ant, you wouldn't need to read books like this either.
Even if you didn't know ant, the online documentation is sufficient. That is how I learned ant.
-=Lothsahn=-
Hey, make fiends, try this: add new functionality to make, extending its syntax. PITA, you say. It's very simple with ant.
You can. But you should not. You're falling into the Turing Tar Pit. The C and C++ building facilities are too immature for now. And the Ant developers certainly are not putting priority in making it work well with C and C++ building anyhow.
FYI: I use Ant to build/test/deploy my Java code.
Given that I've spent about 1 year working on legacy makefiles at different companies, I am glad to see make phased out.
I'm much more productive using something other than make for building multi-project software packages.
This book is also available online at O'Reilly's Safari site.
Also, although Ant is used mainly to build Java, it is NOT java-centric. It can be used to compile any language.
Can someone explain to me the difference between Ant and Maven? I have noticed almost everyone supports Ant, but there are people who also do Maven. Are there any advantages, disadvantages, are the different but overlap greatly, and why does Apache support what appears to me to be two competitive technologies...
Very confusing to someone who just has a high-level understanding of Apache world.
D.O.U.O.S.V.A.V.V.M.
There is a port of Ant to .NET available from here.
It had a great following until MS announced MSBuild.
Unfortunetly, MS put RIP on it when they created MSBuild, which comes with .NET. Visual Studio project files are MSBuild files.
1. The pulling teeth part! You need to use the 3rd party ant-contrib package to even get basic if-else and for loop functionality. And even then, since it's XML, you end up with crap like this:
.class file or somesuch. What ant needs is something like what gcc -M does for make.
<if>
<equals arg1="${foo}" arg2="bar"/>
<then>
<property name="bat" value="barf"/>
</then>
</if>
... give me a break.
What I'm always hoping for is a build system that is just a perl / python library, so I can write the build script in a real language and call the build system when I want to.
2. Ant's simplistic rebuild-on-file-mod way of doing things misses things. Say class A.java calls class B.java. You build and all is well. Then you change B.java's interface, but not where it is called in A.java. By right your build should break now, but ant only rebuilds B.java, because it's file mod time is updated; it does no analysis of what depends on it and should be rebuilt. So you run the program and if that line of code gets called you get a NoSuchMethodError, examine that stack trace, and manually delete the
... hey, I use it, but it's the year 2005 for crying out loud.
make is awful. Different operating systems have different command line syntax, different path separators, limits to command length, etc. And which make are you using? nmake, dmake, bsd make, etc? There are tons of different make programs, many of which are subtly incompatible with one another and sometimes incompatible with different versions of themselves.
So if you can tightly control the operating systems you are distributing to and tightly control the versions of make you are using, make is a fine solution. For those of us who distribute open-source code, make is an absolute nightmare. How many of us want to repond to someone claiming they can't install our software or VMS? Admittedly, some don't care, but I don't want a reputation as someone who distributes non-portable software. (Note, this isn't intended as a flame. Your needs are likely completely different from my own and make may suit them perfectly.)
Has anyone used Ant with other languages besides Java?
If it's Java only, then I just don't care... scons is pretty neat for c/c++, haven't used it on other languages though.
music - http://www.subatomicglue.com
Well, as a sysadmin in a big J2EE shop, I spend about half my time fixing other applications' and other peoples' broken XML, so dealing with ant is no different. Most people around here see ant as a make-equivalent.
I was under the impression that XML was designed to be written and used by machines with little intervention from people. Some people insist it's a programming language. I hope those people burn in heck.
Give a man a fish and you have fed him for today. Teach a man to fish, and he'll say "WHERE'S MY FISH, YOU IDIOT?"
I know Make. Make is a friend of mine. Ant is no Make.
.bat or shell script...but that's sadly about where it ends.
.bat/shellscript replacement...and that's it. Claiming it is a legit replacement for Make is to completely misunderstand what Make actually is and does. That doesn't mean Ant isn't useful, it is, but it is no Make.
Ant can automate Java builds slightly better then a
The major problem is that Ant has no built in dependancy system. Dependant tasks don't count as they have no targets and thus nothing to check for dependancies. All real dependancy checking in Ant is embedded in the Ant task code...which varies task to task and worse yet has little to no documentation (not even documented to be taking place or not!). Examples are javac, zip, copy tasks.
Ant + Javamake gets closer to a Make replacement, but not completely.
But really, to be accurate Ant is a portable
My
Another great tool that I'll never use.
There is only one true make, and that is GNU make. Works everywhere, including on VMS.
Your complaint belongs in the late 80s or so.
It has been a source of constant dismay to me that something has not arisen to replace Ant in for Java builds. The Ant project has created a terrific mess where people essentially *program in XML*. XML is a set of data structure markup semantics, not a programming language. No potential of repurposing ant build files exists, another knock against using XML. Therefore, from a software architecture perspective, Ant is one of the biggest misapplications of technology I have seen to date and despite that, staggeringly popular. I rest my case and shake my head.
But I prefer to use make and a Makefile to compile my Java stuff because make is available on every Unix by default.
.JAR file. You have to have Java to run it.
/usr/ant (or wherever). Do 'export ANT_HOME=/usr/ant; export PATH=$PATH:$ANT_HOME/bin' - or make symlinks as appropriate, and voila, it's installed.
This is such a ridiculous assertion. Lets take this apart for a moment.
First of all, Makei s not available on every Unix by default. You have to install it from whatever distribution methodolog you happen to use.
Once it's installed, you STILL have to install the JDK for ANY application you're building, no matter what. You're a java developer, ergo, you need the JDK. With me so far?
If you have the JDK installed, you have a Java VM. Ant uses the Java VM (it's distributed in binary form as a
So, by your own definition here, every platform you'd be developing or running apps on will run Ant. So much for that excuse.
Moving along. Installation of Ant is TRIVIAL. Unpack the distribution into
Remember, Ant will run on every system that Java runs on, which is every platform YOU'D be working on.
If you want to use Make because you're used to it, more power to ya, but don't use false statements to justify your own preferences.
Event Management Solutions : http://www.stonekeep.com/
We're using Ant with PHP. It's working out just fine. I'm preparing an article on an interesting technique we're using to manage multiple projects with a bit of sanity, and Ant is the cornerstone. If you're interested in a draft, email me at mgkimsal@gmail.com or check http://webdevradio.com/ in the next few weeks.
creation science book
You can. But you should not. You're falling into the Turing Tar Pit. The C and C++ building facilities are too immature for now. And the Ant developers certainly are not putting priority in making it work well with C and C++ building anyhow.
This is a reasonable point. However, the original post mentioned C or C++ as part of a general Java project, so any support should be adequate. For better or worse, ant is Java-focused, so C and C++ building is not going to be a priority.
Make is for C programmers,
Ant is for Java programmers,
Maven is for idiots.
Regardless of whether or not that is true (I wouldn't swear by it), the point is not whether or not everyone can use the particular version of make I want them to use. It's whether or not the version of make they actually do use is compatible with my Makefile. That's why Java has Ant. That's why Ruby has Rake. That's why Perl has Module::Build. That's why more and more open-source software projects are realizing that make doesn't cut it. Just because you think that GNU make is superior to Solaris make (which behaves quite differently in many cases) doesn't mean that that a Solaris shop will easily convince their admin to install your version of make just because you have a personal preference.
You should read up about the limitations of make and compatability issues of different versions.
Your complaint belongs in the late 80s or so.
Your defense belongs in the late 90s or so :)
I have to sort through a bunch of noise - the tags
As against what? Some arbitrary and undocumented text format?
XML syntax is mostly noise with a bit of data thrown in and delivers on none of it's promises.
What utter nonsense! Of course XML has delivered. An example is the Open Office document format, that is XML-based, easy to transform to other formats (such as PDF), and because it is XML (open and documented) is also now accepted by KDE office applications.
besides, what's stopping you to use make should you create your own java sysadmin tools?
Nothing, except that Ant has a huge amount of support for Java and associated tools. Almost every tool and product developed to assist Java developers provides an Ant library to add functionality. To work with 'make' would be a huge step backwards.
Unix originated the idea of the tab-delimited file as a simple way to delimit fields and records (with a character that was unusable in the field data). But it quickly fell from favor because text editors were inconsistent when 1-byte of data did not equal 1 space on-screen. The tools failed them so they abandoned tab-delimited file formats.
Oddly enough, the ancient Mac OS (pre-OS X) users had big problems with columnar-aligned, fixed length formats for file formats, mailing lists, and database dumps because the users didn't realize that the proportional fonts weren't properly aligning the data. The tools failed them so they adopted tab delimited file formats.
Now that Mac OS and Unix have sort of come together, I find the quality of tools on both sides could use some improvement. I've found a wealth of data editiing tools that make make editing columnar, tab-delimited, or XML data a pleasure to work with.
The real answer is to spend time to improve the tools if you're not the one in control of the formats.
And converting them to XML won't change that, because unless you're dealing with files that are very much more complex than the ones in
Ant-contrib offers a C / C++ build task, and I've used it with a lot of success for building the .so libraries that my JNI calls will use.
The documentation isn't great, actually (when I used it) it sucked, or more to the point, I couldn't find it. Finally I found an open source project that used the task successfully, and used thier build.xml file as a template for the compiling I had to do.
Mabye I'm being too harsh with respect to the documentation, since a quick look over at http://ant-contrib.sourceforge.net/cc.html seems much more comprehensible than I remember it a few years back.
The best thing about using FORTRAN it that I don't need to read books about C.
The best thing about C is that I don't need to read books about C++.
The best thing about C++ is that I don't need to read books about JAVA.
The best thing about Lisp is that I don't need to read books about Carly Fiona.
The best thing about AWK is that I don't need to read books about Beowulf Clusters.
The best thing about bash is that I don't need to read books about hot grits.
Your statement is truthful, but lacks substance.
Ant: toolkit for building, declaratively (e.g. say "please compile/javac these stuff, and how" instead of specifying "javac -classpath ... -d ... File.java"
Maven: a framework or skeleton your build will follow, declaratively. "This is the source tree..."
If you don't mind forking to run external tools, instead of running in the same VM, you could use the native build of ant using gcj as sponsored by Red Hat.
Contrary to popular belief, GNU make is no lightweight. Sure, the make executable is lighter than and + a JVM, but the first thing the make executable calls will be a shell, and that will be calling a program, and you'll use many many programs to do anything that isn't trivial.
Worse yet, make runs each task in a new shell, so you'll have many many shells being created and destroyed. If your project grows to any considerable extent, you'll soon see ant's solution of one shell (the JVM) as a lightweight solution, even if the shell itself is bigger.
As long as you can comfortably fit into a declarative, purely dependency-oriented structure, Ant is great. But as soon as you have to cross the "scripting divide", which has happened with every nontrivial system I have dealt with, Ant becomes really clumsy. To me, the SCons approach of providing a build and dependency management framework that you can easily invoke from a general-purpose scripting language is much more elegant.
Other replies have mentioned that you can build anything, do anything with Ant.
The thing I want to add is that Ant is cross-platform. Not just cross-platform like the gnu toolchain, but cross-platform in that e.g. a copy command is implemented using an XML element and system variables for paths... that way you can conceptually have exactly the same build process on a wide range of systems, within reason. (You don't need to know if the copy command is "cp" or "copy" on the target system.)
Make yes, but make is nothing more than an extended batch processor with a lousy syntax, make relies heavily on third party tools, which you might not get at various platforms make itself runs on. One of the big advantages of newer build systems like ant is, that you do not need those third party programs anymore.
No, really, I'm not kidding.
Defining your dependencies in Prolog or some similar language makes all kinds of sense.
Let's put it this way. I would have no problems telling my boss that we should use ant to build Java projects. But I would not risk it if we were doing C/C++ projects.
Ant and C/C++ is not ready for professional use. That's why the facilities are still in the "contrib" tree, and not the offical one.
And why on earth should there be one? You have to have domain knowledge to parse a file format and do something meaningful with it. Sure, if the file format is a specialization of XML, it helps you find some broken syntax on the XML/DTD level, but the penalty is this horrible tag soup which is never parseable with standard tools like grep, cat, awk etc.
I cannot see why XML people find it worth all that trouble. One language for one purpose is fine with me. This applies to make too -- the language fits the purpose of the tool well, and the TAB issue has never gotten in my way during the maybe twelve years I've used it.
And why on earth should there be one? You have to have domain knowledge to parse a file format and do something meaningful with it.
No. You don't have to have have domain knowledge to do this. For example, with XML, you can do things like 'extract the contents of the second element' with any XML file.
I cannot see why XML people find it worth all that trouble. One language for one purpose is fine with me. This applies to make too -- the language fits the purpose of the tool well, and the TAB issue has never gotten in my way during the maybe twelve years I've used it.
How about the reverse view? Why invent a new format for each purpose, requiring specific domain knowledge even to begin to make sense of the file contents?
penalty is this horrible tag soup which is never parseable with standard tools like grep, cat, awk etc.
Having a range of files with tab, or comma, or colon, or other arbitrary delimiters isn't horrible? This is a kind of delimiter-soup which can't be parsed with standard tools unless you already have detailed knowledge of what the delimiter for a file is.
I have been using Ant for a while now and my experience is that although it is possible to do things other than build Java, I am fighting against a lot of strongly built in assumptions to get it to do anything else well.
Given that Ant uses XML and has an XSLT task, you might think that it would be good for doing XSLT processing, but if you need to use a more advanced XSLT processor (e.g. Saxon) you immediately run into problems. It would not be a big issue if I was working on my own - I could just dump all the extra jars into my Ant lib directory, but that is an administrative nightmare if you are one of a team. You can't even give a colleague a copy of Ant with the extra jars in place - if they have Ant installed and ANT_HOME set, it takes priority and chaos follows.
The review also refers to "excellent online documentation" but I have to disagree with that assessment. After using the online documentation most days for several months I have learned how to find what information there is on the things that are not used much in the endlessly repeated trivial examples, and that what is there can be rather misleading.
Having just looked at what you can get at the O'Reilley Safari site without subscribing, I am not going to get this book. The chapter outlines and summaries cover the same old stuff, heavily Java focused, and not straying far from the conventional view of what people might want to do.
Ant is better than nothing, for Java development it is better than make, and for things I am doing on my own I can bend it to be useful beyond those narrow limits. It falls far short of the hype put about by its advocates.
a good "do what I mean" XML to XSD translator.
"...verify the XML configuration files by verifying the XML files against their respective DTDs or XSDs"
I really don't have anything against ant and have a small amount of experience with it. The prejudice against XML might even come from not actually having access to the XML DTD or schema itself in a lot of cases. One fears what one doesn't understand. For example, I have to mass-administer SunONE web server, which stores its configration parameters in a dog's breakfast of several XML and flat files. I can randomly hack the files with perl or sed, and then test each hack to see what it breaks, or if I knew the DTD I could actually make some intelligent decisions about what to do.
Sysadmins should learn more about this stuff, because a lot of programmers are trying to do sysadminish stuff in XML, like the Bourne shell commands embedded in XML, mentioned in a parent. Ick.
Give a man a fish and you have fed him for today. Teach a man to fish, and he'll say "WHERE'S MY FISH, YOU IDIOT?"
The format is full of syntactic noise. A much simpler format could have been devised if A) They weren't so interested in maintaining a "text" format regardless of data type and B) They had described the data more completely in the tag, including data size to reduce the need for a closing tag. This would also have eliminated the need to escape data. The format would have then been more terse, less redundant, and more easily editable and parseable. The requirement to stick to a text style formats was unneccissary as since the parsers were being supplied, the editors would have been trival to write.
Add to this redundant constructs (elements and attributes are semantically identical, but syntactically different), the need for external validation due to the fact that conforming editors were not supplied, and the need to walk the entire file to simply read an arbitrary node because although all data to offset directly to an index is calculatable at construction it is not supplied, archaic document definition standards, no thought put into stylesheet application for rendering, and the idea that it would make a good language (template OR procedural) in addition to data storage, and you have a poorly thought out and implemented standard.
It was adopted anyway because standardization trumps all of the above... but that doesn't mean it's good.