FAQ

Q: How is Water different from other Web services solutions?
A: Web services are native to Water, rather than cobbled on after the fact. This means the user need learn only Water rather than the dozen (see question: "How is Water different from Java?") programming models required to create Web services with other languages like Java. Water is based on the XML syntax, which has become the lingua franca of the Internet.

Q: What does it mean when it is said that Water uses XML syntax? Is Water source code itself able to be parsed by standard XML parsing tools? Is there an XML schema (DTD) for Water source code?
A: The Water language uses the ConciseXML syntax which supports both XML 1.0 and concise form. Although Water code can be written in XML 1.0 and parsed by standard XML parsers, there usually is not a good reason to do that. You would need to interpret the code to do something useful with it. In 99% of the cases, you would just use a Water runtime engine (such as the Steam Engine from Clear Methods) to execute the Water code. Most of the time, you will just want to create interfaces to other systems using XML 1.0. Water V3.10 has a 'normalize' method that can take many different styles of representing data in XML 1.0 and normalize them into a standard ConciseXML form.

Water Contract is an XML schema language that uses defmethod and defclass from the Water language to define typed APIs and data structures.

Because you can define your own XML tags in Water, there is not a fixed XML Schema or DTD for Water code. Because every Water object has a well-defined Water Contract, you could output an XML schema or a DTD when Clear Methods develops a Water Contract to XML Schema conversion tool.

Q: What is the difference between Water and ConciseXML?
A: The Water language uses the ConciseXML syntax. The ConciseXML syntax is further described at www.ConciseXML.org.

Q: What is ConciseXML?
A: ConciseXML is a compatible variation of the XML 1.0 syntax. It is a superset of XML 1.0 and eliminates both the verbosity of XML and its ambiguity.

Q: Why would I want to use the XML syntax in a programming language?
A: The XML syntax is the most common syntax in the world. All three billion HTML pages on the Web use an XML-like syntax. With the extensions added by Concise XML, Water can easily accommodate named as well as "by-position" arguments, any data type as an "attribute" value and ending tags that don't have to redundantly mention the name of the tag. Concise XML is actually a simpler syntax than many programming languages such as Java (far fewer "exceptional" cases) plus it has a lot more flexibility.

With data and presentation already presented in XML or XHTML syntax, this permits a single representation for data, logic, and presentation. This eliminates mapping around the incompatibilities in the alternative languages. It also permits making the data elements as dynamic as necessary.

Q: Why would I want to use XML for business logic?
A: There are major benefits in using a single syntax for all tiers of computing in terms of simplifying application development and support. The Water language delivers these benefits. Water is based on the well-known and understood XML syntax, but this is not strictly speaking using "XML for business logic". Clear Methods offers a non-proprietary solution for business logic that is easy to understand by humans as well as computers.

Q: Is it not always better to keep presentation and logic separate?
A: While there are benefits to keeping the different discrete parts of a program separate, this does not imply that they should be written in completely different languages. Designing the entire application with one language simplifies its understanding, development, maintenance, and enhancement. Water gives the programmer much more control over the modularity of their program than multilanguage solutions. Keeping presentation and logic separate is just as easy if not more so in Water. With Water the programmer makes that choice.

Q: Wouldn't a special-purpose language be better for Web services?
A: Applications that require several special purposes languages impose the challenge of merging them all into a smooth flowing, easily supported solution. There is often no perfect boundary between languages. Each language has its own schedule of new version releases, creating a complicated environment for the user to track. Overhead, often significant, is incurred calling among them. Water is an "all-purpose language".

Q: But does one-size fits all mean that the language is not optimized for any one part of an application? Will I be writing in a language which is not best suited for the job at hand?
A: It is important to separate out the "micro" or single method call level from the macro, or interacting methods and classes to understand this issue. At the micro level, the syntax does not so much matter as long as the user understands it and it is flexible enough for the task at hand. Water, by providing a single syntax for method calls makes it easy for the user to "learn once, use everywhere". You don't have look up whether or not you need commas between arguments or semi-colons or curly braces. Water uses none of those syntactic idiosyncrasies. . Water allows default values for arguments, allows by-position as well as named arguments and has the ability to define methods with an unlimited number of arguments. Java has none of these features. Water syntax is often better than a narrow-purpose language even for the functionality that the narrow purpose language supports. Just as important as the micro syntax is the macro syntax, the way that larger pieces of your program are connected together. If this involves connecting code or data written in two different languages, as is common in typical web applications, you must not only learn both syntaxes and semantics but also how to convert the data from one language to the other. Even after you get close on your first pass, multi-language debugging is a nightmare.

Even though we try hard to present everything in one syntax, sometimes this just isn't practical. First using XML and HTML come for free by design from Water. If you know XML/HTML syntax, you know Water syntax, though learning Water's extensions will help with both XML and HTML. Next Water has a very simple to use interface to Java making it easy to call any built in or user written Java methods and constructors. Water also permits programmers to use regular expression syntax for string matching and SQL syntax for making database queries, though for each there is a Water equivalent that gives you more power should you need it. Finally, Water is a language for writing languages in. By using evaluation kinds, you can control how your program parses and interprets arguments to methods and object constructors. So it's easy to define your own methods and classes that have considerably more flexibility than conventional languages.

Q: Is Water Object-Oriented?
A: Yes, unlike Java, everything in Water is an object: numbers, methods, classes, arrays, etc. Water has a particularly flexible object system that makes it easy to extend programs well beyond their original specifications. Since you can dynamically extend Water objects on the fly, it is simple to do many kinds of operations that would be difficult or impossible in most languages

Q: How hard is it to learn a new language like Water?
A: Water is based on the well-understood XML syntax, uses plain English rather than "programmerese", is unambiguous, and maintains consistency. Most new users are able to write useful Web services applications during their first day with the language. Water programmers can learn Water and implement their applications incrementally.

Q: What are the benefits of "pure Web services integrated with XML"?
A: The Water language approach avoids the translation to and from XML as data travels from one corporate system, across the Web to a different corporate system. Below is a comparison with and without a pure Web services platform.

Figure 1 Multiple translations are required without a pure Web services platform.

Figure 2 With a pure Web services platform multiple XML translations are eliminated.

Q: Can Water handle my complex database applications?
A: Yes, Water has the built-in database capabilities.

Q: Is Water compatible with XML?
A: The syntax of Water is ConciseXML which is backward compatible with XML 1.0

Q: Why does Water not use SOAP, WSDL and UDDI?
A: The capabilities provided by these standards are built in to Water, rather than tacked on after the fact. By using Water, the programmer need not track these standards and modify the software each time a new version of the standards is released.

Q: Does Water have enough performance to meet my needs?
A: Performance needs are application dependent. While Water is currently implemented on Java, its consistency allows caching of business logic and data on any tier to optimize performance. This can yield an ideal balance of distributed and central control while dramatically increasing performance.

Q: Is XML too verbose to be the basis for a language?
A: ConciseXML, the syntax of Water, solves the XML verbosity problem, and is backward compatible with XML 1.0.

Q: XSLT is too complex and slow, so will Water have the same problem?
A: Water can replace XSLT functionality and is simpler, faster, more versatile, and more concise. By using XML syntax, Water parsing is transparent, just as the Java parser is transparent to the Java programmer.

Q: How does Water compare with XSLT?
A: XSLT is difficult to learn and can be very difficult to debug. For example, you cannot set breakpoints and often cannot tell when an error has occurred. XSLT error messages tend to be unhelpful. Even simple things, such as a counter are difficult to code. The resulting application is hard to decipher. This is compounded by the fact that few good tools are available for XSLT.

Typical XSLT users must work in not only XSLT, but VBScript, ASP, XSLT, XPATH, parser, JavaScript, CSS or Java. One language, Water, replaces all of these.

Water allows for a clean separation between logic and presentation. Water can perform XSLT-like functions, but without the complexity and hard-to-debug nature of XSLT.

Q: Why do I need a new language like Water when I do my programming with higher level tools like .NET Studio?
A: While tools like .NET Studio mask some of the difficulties in programming .NET applications, they often do not allow enough flexibility to develop fully-functional applications. Nor do the higher level tools provide help in maintaining applications that were developed by others. Developers typically find that after a short period of time they need to work directly with the code as the tools prove too restrictive. At that point, the developer is faced with the full complexity of the .NET environment.

Q: How does Water compare with .NET?
A: The .NET platform attempts to mask the complexity of XML and Web services through wizards and other graphical tools. It does not provide the general purpose flexibility that businesses require and that Water and Steam provide. A common scenario is for an IT developer to bring up a sample application in .NET using Wizard. However, when real business requirements demand complexity and adaptations, .NET breaks down. The developer often does not understand enough about how things work behind the scenes to effectively support and modify the application.

The .NET platform makes only a subset of XML functionality available. If you can not represent something in C# (for example, default arguments), then .NET does not let you represent it in XML. It is incomplete.

.NET is successful in making it easy to build in Microsoft's new Java-like language, C#, and then generate the XML interfaces. But, there are problems with interoperability. .NET does not help when people send you XML that wasn't generated by .NET. The platform still requires a dozen or more languages and technologies, including ASP, ADO, JavaScript, C#, SQL, and XSLT.

Many Visual Basic 6 programmers feel that the learning curve for VB.NET is steep and that VB.NET is much more complex and less productive than VB6.

The .NET platform is quite large. The Steam platform is very compact and can fit into smaller devices.

Q: Is SSL support part of Water?
A: SSL is not yet supported in Water.

Q: Is Water another proprietary language?
A: The specification for the Water language is open. We recommend the Water syntax, ConciseXML, as the direction XML standards should go to solve the most significant limitations of XML 1.0.

Q: How will a new language like Water ever gain broad usage?
A: Water is being adopted for several important reasons. It solves a major challenge in Web services application development - the complexity of the development environment. Its acceptance is accelerated by the wide spread usage of XML, the basis of the Water syntax. In fact the XML and HTML subsets of Water have already been widely accepted!

Q: Is Water only appropriate for new, greenfield applications?
A: No, Water can be brought into existing applications incrementally as new capabilities are needed. It also provides an excellent solution for enterprise application integration.

Q: I am quite happy with Java and J2EE. Why would Water be interesting to me?
A: If you are 100% happy, then there may be no reason to change. If, however, you are finding it costly to keep up with the dozens of different evolving programming models required for Web services; or you are unhappy with the inefficiencies of translating into and out of XML for Web services, then you will find Water a highly efficient, easy to use language for your applications. You can adopt Water incrementally as you upgrade your applications. The Water benefits will be brought to bear as it is implemented. Note that you can easily make use of your existing Java code by calling the Java modules from Water programs.

Q: What about my SQL database applications?
A: The Water language also handles database applications.

Q: Does Clear Methods think that Steam can compete head to head with .NET and J2EE?
A: Steam can provide a level of simplicity, flexibility and productivity not available with .NET and J2EE. It offers an alternative to Microsoft's proprietary solution and to the multilanguage approach of J2EE. Clear Methods believes there is room in the market for all three solutions.

Q: I'm a manager and considering using Water for my next project, since I think this will bring a big boost in productivity. But I'm concerned that my existing staff won't know it and won't be able to leverage their expertise in other technologies.
A: First of all, any of your staff's experience with HTML and XML will be directly useful in Water. In fact, the Water environment makes it particularly easy to create and test XML and HTML snippets. Second, Java programmers can continue to program in Java, or at least keep their existing Java code and call it from Water. It's easy to combine Water and Java code and use Water to greater extents as experience with the language grows. Regular Expression and SQL can similarly be used as is from a Water-driven program; the syntax of RegEx and SQL can be gradually migrated as increased functionality is required. Water does have a number of innovations that may take some growing into. But per functionality, Water is simpler to learn than any other language, and there is more functionality than any single language in common use today.

From a managerial perspective, there are other reasons to adopt Water in addition to the major productivity gains. Typically you will have someone on the programming team working on presentation (HTML), someone on data, (SQL), someone on code (Java), someone on documentation (Javadoc or HTML), and someone testing (variety of tools). Water can perform ALL of these functions with one syntax and one set of object-level semantics. By speaking Water, all can share code, rather than just abstract ideas which frequently introduce "errors of transmission". Furthermore, when your staff knows one language and that one language can be used for all of the tasks involved in a software project, it is easier for people to perform tasks outside of their area of expertise when the need arises.

For example, when you have a project on a tight budget and do not have a QA specialist available, your programmers may have to write the tests themselves. Since quality is of the utmost importance, testing is a necessity. But, asking a programmer to write diagnostics is like asking them if they would like their teeth pulled. Though programmers hate to write official test suites, they do, none the less write code snippets and method calls to see that their code follows the typical use case. With the Steam IDE, every method call you write can turn into a test case just by selecting it and choosing the "test" item on the right click menu. Selecting the call is as easy as double clicking on the open angle bracket.. This process executes the code and wraps it in a call to test with the result as the comparison value. The test is called to verify its accuracy. For example, if you were writing a new "add" method, you could

1. Type into the editor buffer: "2.<add 3/>"
2. Double click before the 2 to select the expression
3. Choose "test" on the right click menu to see in your editor "<test 2.<add 3/> 5/>" and to see 'Test Passed" in the lower right output window

Writing tests, like writing documentation, was designed to be so easy in Water that programmers will actually do it. Likewise, when the user interface designer needs go beyond HTML to add conditional logic to customize the UI, it is simply a matter of using the "if" tag, which has the same syntax in HTML. In short, Water gives you staffing flexibility along with software flexibility.

FAQ

Frequently Asked Questions Regarding Clear Methods, Water and Steam