XML is not all it could be. Despite all its promise for free data exchange among disparate applications, Web application developers still contend with XML’s shortcomings: it’s too verbose, it’s too ambiguous to be a true standard, and standards bodies are pulling it in a million different directions. Mike Plusch, CEO/CTO of the Cambridge, Mass., startup Clear Methods, cites these flaws, along with the complexity it breeds and the static manner in which it’s often used, as obstacles that have left the language’s dynamic potential for Web-based programming untapped.

Plusch, a Web development veteran of more than 10 years, believes he and Clear Methods co-founder Christopher Fry have a powerful yet simple solution: XML as a general-purpose programming language. With Water, Clear Methods’ object-oriented programming language, developers can write executable code in XML, describe persistent structured data on the Web with a simplified, XML 1.0-compatible syntax called ConciseXML, and still utilize the widely known markup capabilities of HTML.

Clear Methods licenses Steam, its development platform for Water, which includes a runtime engine and an IDE. However, Water has a freely available runtime and is openly documented at waterlanguage.org. Designed for deployment on any tier (data, logic, presentation) of a Java environment, Water is flexible enough to replace any special-purpose language that a developer may need to support in today’s heterogeneous Web application environments. “The idea,” explained Plusch, “is to establish Water as the XML language of choice and then sell the business tools to use it.”

XML as Clear as Water
What frustrated Plusch about XML, particularly XML 1.0, and led to his creating Water was chiefly its ambiguity. The XML 1.0 specification is not only verbose?a common developer complaint?but it also has multiple representations for the same object, which causes an ambiguity problem. To define the problem, Plusch offered this hypothetical: “If you asked 12 developers to present an XML representation of one object, you’d probably receive at least 12 different representations?and probably 24. Each developer likely would present one representation that he or she would find too verbose and then submit another, stripped-down version.” ConciseXML, so named for its less verbose syntax, has only one XML representation for a given object.

Plusch believes Water addresses the shortcomings not only in XML itself but also in the ways vendors and developers have used it. Developers commonly treat XML as a static hierarchical representation instead of as executable code. Plusch acknowledges that there are thousands of XML generators, but says very few of them execute it, in terms of treating XML as program code. “Clear Methods is the only one that actually executes XML,” he said.

Plusch also believes vendors are misusing XML and consequently ignoring its power. “Companies are treating XML as a wrapper,” he explained. “They’re just bolting it to the outside of their programming languages.” For example, Plusch points to JSP wrapped in XML for transport, a scenario in which the XML can actually offer more functionality than the Java itself.

Programming for the Web Today
XML data exchanges via the Web are often complicated by the myriad customizations that developers perform to have XML fit their individual environments. They employ any number of the dozen or more special-purpose XML languages available. The resulting differences in semantics, syntax, and interfaces among organizations can be significant barriers to an open data exchange and present quite a burden to developers. Plusch pointed out that as easy as exposing data in XML is for these programmers, enabling their applications to consume the various flavors is much harder. He said, “With all the incoming XML data, developers need a flexible way of consuming it all.”

The advent of Web services has done nothing but obfuscate matters, according to Plusch. With its own set of varying languages and standards, Plusch says, “Web services [development] adds complexity on top of complexity.”

Another XML Language Is Supposed to Simplify Web Development?
A developer who is confronted with all the languages he or she must support in today’s heterogeneous environments may view Water as yet another language to throw on an already overwhelming heap. Unless everybody’s using it, how does Water simplify my day-to-day support, he may ask. And who has the time to learn another language?

According to Clear Methods, “Water extends the syntax of XML to make the language less cumbersome to write code in. The new language provides a way to define and call functions in addition to defining and instantiating objects.” In other words, a programmer who is familiar with XML syntax does not have a steep learning curve for Water and can begin using it right away to replace any programming languages he or she is using. “An HTML developer can learn the basics in a few days, yet a Lisp or SmallTalk developer will feel right at home with Water,” wrote Fry in his paper, “Water Rationale.”

Because Water is pliable enough to use for code, data, and markup, developers can also choose the tier to which they want to apply the language. Its general-purpose functionality enables developers to, as Plusch put it, “learn once, use everywhere.”

Early Adopter: Come on in, the Water’s Fine
Ben Koo, a PhD candidate at MIT who is conducting research to model complex IT systems, has been involved with Water for two years. He initially was intrigued by the ability to apply the language across all tiers. As a former system architect of large-scale IT systems at huge corporations such as AT&T, he appreciated the simplification Water could offer as a cross-platform language. From his current work, he has also gained an appreciation for Water’s modeling capabilities.

“Water as a programming environment has modeling because of its Lisp underpinning,” he explained. As a language and a modeling tool, it can represent and store XML?syntax just about everyone knows?and execute the code, said Koo. He compared this functionality with other tools he’s used. “Traditional modeling tools, such as UML, are domain-specific. They become very constraining,” stated Koo, adding that UML doesn’t execute code. “CORBA’s interface definition language is too convoluted,” he added, while Water has a small runtime engine and borrows XML’s well-known structure and definitions.

The feature Koo most values in Water, however, is its simplification of object-oriented development. Koo explained, “Over-simply put, object-oriented development is about namespace management.” He understands the benefits of “using object-orientated development as a concept” but admits that “libraries take a long time to master.” Water offers what he refers to as “namespace management on top of Lisp management,” or XML as a method for management and Lisp as the runtime engine to execute it.

The only improvement Koo said he would like to see in future releases is in Steam’s user interface. He believes Clear Methods would do well to “improve the look and feel of the programming environment, and add more function. It needs some kind of graphical interface; the artwork needs work.” Specifically, Koo said that although it’s already functional, Steam needs a file management extension.

Just Add Water?A Sip at a Time
By adding programmability to XML, Clear Methods offers a general-purpose language that can replace all the special-purpose languages developers are using to accommodate Web-based applications. At the same time, it has the flexibility for implementation into any tier and task level. This allows for incremental adoption, which Clear Methods has dubbed its “sip of water” strategy.