My main experience with XML-based programming languages has been with VoiceXML. One nice advantage of an XML-based language is that the syntax checker is essentially free, assuming the language provides a DTD, or preferably a Schema. Of course, most language compilers and interpreters also come with a syntax checker, so the DTD/Schema advantage is primarily a time saver for the language creator.
The Ant build program also uses an XML-based programming language. I’ve written quite a few Ant build files by hand, and the experience has brought little joy. However, writing old school make files was even more frustrating. The many problems with the use of XML with Ant have been noted by Bruce Eckel, Martin Fowler, and Patrick Logan. Patrick points out YAML as a possible compromise.
VoiceXML has the further complication that good VoiceXML applications tend to be a lot more dynamic than build files. Since the goal of a VoiceXML application is to create a natural sounding, automated voice dialog, you generally want to customize the dialog for each caller and to slightly vary the spoken dialog on each call so as to avoid a completely robotic, scripted effect. While you can accomplish this to some degree with static VoiceXML files, it’s far easier if you dyamically generate some or all of the VoiceXML at runtime. With an Ant build file, I think it would be rare that you would want to dynamically generate the build script every time you run it.
Manual creation and editing of Ant files and VXML files is frustrating and limiting. The resulting files seem overly verbose. Because they are so verbose, it’s difficult to keep large sections of the code in your head at one time.
Because manual VoiceXML coding is so difficult (hand-coding SALT-based applications is even worse) a lot of vendors have developed SDKs or graphical IDEs that mostly or completely hide the VoiceXML code from the developer. The good news is that this opens up speech application development to a lot more people. For the advanced developer, it also makes it easier to create large, dynamic applications. Of course, there are always downsides.
In my opinion, the biggest disadvantage is that most of these SDKs and IDEs throw portability out the window. While VXML code is relatively portable between different VXML browser implementations, the IDEs typically don’t generate VXML directly. Instead, they generate an intermediary form, usually consisting of POJOs (Plain Old Java Objects), servlets, JSPs, and/or XML files with custom tags. The intermediary form must then be processed by a server runtime layer that sits on top of a web or application server.
Nonetheless, there are several very good reasons that the SDK and IDE vendors have gone down this path:
- Markup languages like VoiceXML and SALT are too low level for large, sophisticated applications.
- Many developers, especially those in IT groups, prefer drag-and-drop graphical IDEs
- Mapping of VoiceXML tags directly to graphical forms would provide only minimal abstraction for a new developer
- The abstraction from VXML means a tool could theoretically use a single dialog design to dynamically generate applications in multiple markup languages, like SALT, XHTML, WML, XHTML+Voice, or a chatbot markup language for a single multi-modal interaction
The VoiceXML 3 standard is targeted to close some of this gap, by I haven’t been involved enough in the process so far to comment on how successful the voice browser working group will be.
The closest thing I’ve seen to this situation in the Java world is BEA WebLogic Designer. WebLogic Designer provides a significantly higher level abstraction above not only web services, but also web application and database integration development. The goal was to bring the good parts of Visual Basic to the corporate Java developer. The downside is that WebLogic Designer generates code that will run only with WebLogic runtime components. Therefore, the ease of use advantage costs you portability. Nonetheless, WebLogic Designer can provide a huge productivity advantage to many developers.