One of the things I continually rail about in the Web services world is the lack of last mile technology - you know, the ability to get a Web service in front of a user. Even though a large number of Web services are designed solely for computer to computer communication the continuing reality is that more Web services are designed to interact directly or indirectly with human beings.

The problem, as I've stated before, is that there is no concept of user interface in Web services - no way to go that last mile and reach the end user. We've got a plethora of technologies to solve other problems, such as security or transactional integrity; sometimes we even have multiple standards for solving those problems.

Now, don't get me wrong, I know that having a transactional semantic, as complex as it sounds, is simpler than providing a generic approach to user interface. Computers have different operating systems, with different presentation constructs. Java took a shot at ubiquity of user interface with its write once/run anywhere approach, but the least common denominator approach they took with AWT and Swing left a bad taste in many people's mouths (not to mention that it left many people going to get a cup of coffee while they waited for the screen to respond). Regardless, Java failed to create a ubiquitous front end.

Ideally, we've abstracted the business rules into Web services, so all that's left for the front end is presentation logic - displaying data, acting as a data-gathering device that forwards all requests in coarse grained calls to a back end Web service.

Reality makes it a little more complex, as screen data population (think drop down list boxes, etc.) is rarely part of a pure Web services API design. So some additional Web services are usually needed for screen support.

Mix in things like validation (making sure the social Security number is nine digits, no alphabet characters), dependencies between screen controls (like filtering one drop-down based on the selection in another) and conditional displays (graying out options, or removing screen elements based on selections), and you have something that is more complex than just rendering screen elements. Then try to figure out how to do this in a neutral manner with regards to operating systems, and you have a good idea why no one has wanted to go here.

There is some hope however. Microsoft will be releasing a technology known as Avalon as part of their Longhorn release. Avalon will abstract the presentation logic into a format known as eXtensible Application Markup Language, or XAML. Based on XML, XAML describes the presentation aspects of an application's user interface. Like HTML, it is tag based, but unlike HTML, it's designed to be implemented on a native user interface (Windows, in this case), although it can also be utilized in a browser.

At the moment, no mention has been made of placing this language in open source or making a Web services standard out of it. Let me be the first to urge that this happen. Please, donate this to the community.

It would or should not be difficult to move a language that describes a user interface to other platforms. XAML will also work in Internet Explorer and for all intents and purposes that's a separate platform. And realistically, the language describes screen elements that are nearly identical across platforms anyway - a button is a button is a button, whether it's on a Mac, a Windows machine, a Solaris box, or a Linux PC. Sure there's always the chance of incompatibilities, or dummying down, but I'd take that (in the first release, at least) in exchange for being able to describe my application without code and let the operating system figure out how to run it, and what to display.

So I'm going to keep my fingers crossed. This is a good idea. Finally, the last mile.