A couple of issues ago, I railed about the lack of Web services- based technology to provide the last hurdle of any service - representation in a user interface. While many Web services will only be accessed programmatically, still more are destined to find their way, one way or another, onto the screens of computers in front of human beings.

I got a number of comments on the article, the most interesting one being from a reader who thought I was joking - after all, there already was a last mile technology called the World Wide Web. And he wasn't being facetious either, he was serious.

I can see his point - the Web is certainly ubiquitous. However there are a number of issues that accompany it, issues I guess I didn't make plain enough when I was calling for a different technology to be developed.

HTML is not a programming language. It was never meant to be, so there's certainly no blame to be placed on it from that perspective. At the same time, though, instead of developing a programming language neutral-presentation language, and clients that could consume such a language, the industry has come up with various ways to spew out HTML and accept data back from it.

There are problems with HTML that make it a poor choice for some applications. Data is not separate from user interface; it is all part of a message. Effectively, the interface is sent every time a call is made to the Web server. There is no two-way conversational state - in fact, state is not maintained at all by HTML. There's no way to send a message to the interface, so things like real-time feeds have to be accomplished by some other mechanism.

The visual constructs of HTML are not as sophisticated as those available to the native user interfaces (Windows, or KDE, etc.). Multiple documents, grid controls, sophisticated graphics, charts, and other unique controls are all beyond the reach of basic HTML. Anything addressing those needs is custom, and not part of HTML.

Additionally, not everyone wants to expose his or her applications using a Web browser or over the Internet either. Various reasons are cited, but they include security, performance, firewall issues, or a desire for a rich user interface.

What I was pushing for is a new paradigm, one that Microsoft is testing the waters on. I would like a platform-neutral rendering language supported by a platform-specific implementation (it could be a browser, but it could also be the native user interface itself) that would allow interpretation of the platform-neutral presentation language. It would provide the ability to maintain state, allow for strong security, provide all the control depth that the native UI provides (perhaps with certain tweaks to provide for modal operation, for example). It should allow for bidirectional, asynchronous secured conversations utilizing Web services as a mechanism. It would not need to download the presentation with every request - that would be part of the presentation definition as to when new presentation elements need to be requested (i.e., a table would not need to download its format, just the data if it had changed).

None of this is easy. One of the reasons it has been delayed in the realm of Web services is that it requires new technologies, new paradigms, and significantly, new cooperation.

I mentioned that Microsoft is attempting something of this nature, although limited to the Windows platform. The first step is a descriptive language that will provide for interface creation and element binding. They're pursuing this for the next version of Windows. Obviously this will be an XML-based language. Hopefully, the first step towards a truly platform-neutral presentation will be the donation of this technology to the open source community so that platforms beyond Windows can benefit.

This month's focus is on consuming Web services. Currently there is a number of ways to consume Web services. It's my hope that a few years from now, I'll be telling you about the new, platform-neutral way to consume them. Until then, we'll limp along with HTML and proprietary stop gaps.