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 verbosea common developer complaintbut 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 representationsand 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.
|"Companies are treating XML as a wrapper. They're just bolting it to the outside of their programming languages."|
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."
|" 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."