One reason is to better support automation. With an API and a clear XML format, people can do all kinds of things.
Another reason is to create a natural and strong division between syntax and compiler. If I do that, I can develop a few different languages. That way, people who think curly braces are what slow them down can have a language that uses white space to define blocks and sane people can use curly braces or whatever.
Then there is the main force driving this design decision. Having a clean, platform-independent way of expressing a database design allows me to write, say, a Java client that can explore a database class definition file and expose its structure to Eclipse. I can do that about as easily as I could with a Visual Studio extensions.
There is a consequence to this design. While the XML format is theoretically human-editable, it is not intended to be the primary means of expressing a data class. I'm still committed to having a domain-specific language for that purpose. So, whereas DataConstructor and the sample code for my book use XML as the primary format, I have no intention of supporting that in DataClass 3.
