One Language to Bind Them All
The use of XML as a primary storage medium for code is increasing rapidly. I'm not talking about embedding code content in XML, I'm talking about XML as the representation; in other words, XML-based languages. XUL and XAML
, along with several other display-oriented vocabularies started this trend, using XML to describe items to be drawn on-screen. It's a short step to including code intended for off-screen consumption as well. That's happening too. The Water programming language
was first out of the gate as a commercial product. Unfortunately, simply transferring code storage from plain-text to XML-formatted files doesn't create much value. All the current XML-based languages do exactly that, by storing high-level code statements in XML.
No, the real solution hasn't yet reached fruition because it still slows down processing too much. The real solution is to put standardized primitives (variable declarations, assignments, IF structures, loop structures, function and method declarations, etc.) rather than finished 4GL code into the XML code documents. Doing it that way makes it possible to transform the code into nearly any language capable of expressing the primitive in its own higher-level syntax. For example, a loop, using an integer counter, can be represented generically and then processed into syntax and keywords appropriate to any language. Obviously, each language would need its own translation capabilities to and from its proprietary syntax, but the end result would save billions of dollars, by:
- Giving organizations a verifiable way to pass code into and out of the organization. Companies could use schema and intelligent code parsers, to determine what code does, whether it's dangerous, and even what types of permissions that code would require to run properly.
- Freeing code from the restrictions of the original language. Hire a VB programmer to write some modules, and then later translate them into C++ and compile them with the rest of your application. Take your existing C++ DLL's and translate them to Java code.
- Making it easy to migrate code from one system to another. By translating existing code into standard primitives, and then transforming it into a more modern language, you can avoid many of the problems associated with upgrading from one version to another, or translating from one language to another. This works much the same way as with old Word files. If you load an old Word file into Word 2003, you can save it as XML. Similarly, if you loaded an existing code file into an XML-enabled code translator, you could subsequently save it as XML.
- Increasing code reusability. While the world has made great strides in code reusability already, there's far more progress to be made. If organizations could truly take advantage of code that's already been written and debugged, they could save enormous amounts of money.
Would such a translation layer be perfect? No. There are reasons for different languages. Each has unique concepts and, to some degree, constructs. However, most programmers know that most
code isn't language-specific, and could therefore be translated quite readily. Would it be efficient? No. From a machine-performance standpoint, an XML representation would be far less
efficient than 4GL code. But translation doesn't necessarily need to be efficient. Developers wouldn't work directly with the XML representation; therefore speed would matter only when saving or during compilation. As with other code, hardware performance improvements will eventually make such a representation fast enough.
OSWho Cares? Give Me My XML
The ongoing discussion over which operating system is better for businesses and home users has become pointedly more heated lately, particularly the choice between the various Linux distributions, Windows, or the Mac OS, among others. Freedom of choice, compatibility, convenience, and costas well as widespread anger with Microsoftare the key touchpoints in these debates.
XML is evolving in ways that will eventually make the choice of OS far less important. Operating systems are simply a managed environment to facilitate a few tasks: Running applications, storing applications and data, and displaying documents.
As you've seen, XML is set to fuel both file system (WinFS) and display (XAML, XUL) functionality in Windows. Similar capabilities for other OS's are likely not far behind. If you can capture the application management, data storage, and UI behavior in XML, you've essentially created a layer that can be moved between operating systems much more easily.
As I've already discussed, XML-formatted configuration files increasingly hold directives, settings, preferences, and meta-data for individual applications, which means XML is already being used to perform one portion of application management. Applications also need data, and XML has made significant inroads into data storage, data transfer, and data query capabilities as well. Although relational databases remain the primary repository for enterprise and large-scale application data, modern applications that work with the data are retrieving it as XML. Microsoft's DataSets in .NET are one small example. For more indications, one need look no further than the fact that all major databases can now deliver XML-formatted data, accept XML data for update and insert operations, and are rapidly gaining the ability to store and query (see XQuery) data in native XML format.
The essential point is this: Just as XML Web services provide a language-and-platform-independent layer between applications, XML configuration and management, data storage and display provide an equally language-and-platform-independent layer between operating systems. You'll see the fruits of this added layer of indirection in years to come.
In the meantime, there's a fairly simple way to stay abreast of the most important technological changes lurking in the middle distance: Keep a close eye on all advancements in XML and be prepared to modify your processes to comply with an XML-saturated technology future.