In the history of XML to date, its role in application development has been mostly on the edge - it has been used primarily as the format for applications to communicate with each other, as a way to serialize data or configuration information, or for some other use at the "front door" of the application. The internal data model and processing that made applications run were entirely driven by objects (Java, C#, or what have you), relational database schema, and the like. Developers used the same approach to data modeling they always had and leveraged XML on the outside of their applications.

As XML has become more mainstream, and there is much more XML data floating around the enterprise, new technologies have been developed to better process and manipulate XML inside applications. As a result, the role and location of XML use in applications is shifting. We are starting to see more and more applications in which XML is not just a way to serialize or communicate the already extant data structures, but a way to think about modeling the application data itself.

To get concrete for a moment, think of a Web services application for handling an order. The Web service might define "Customer" data and a set of "LineItem" data that makes up the order. Usually great care goes into defining the structure and the associated validation rules of this data, because it's a lot easier to enforce these constraints in a declarative medium like XML Schema than in a programming language. Today a Web service like this is usually just a thin "XML" layer fronting a legacy application. XML is being used at the edge, and is translated into the internal application data objects (Customer and Order for example) where the real work happens.

New order processing applications, however, are being built with Web services in mind from the get-go, not as a layer tacked on after the fact. In these applications, where you aren't constrained by many existing data structures, you start to wonder why you need to translate this nice data model you defined in XML Schema into the less expressive type systems of a programming language just to write your application logic, only to translate it out to XML again. Moreover, you have to write a lot of code to make sure that the data continues to meet the original constraints imposed by the schema as it flows through the system.

Part of the reason this hasn't been done to date is that accessing XML from within programming languages is just too hard. Either you are forced to deal with low-level XML processing like DOM or SAX, or you have to live with the loss of schema information that comes from translating XML into programming language objects. New technologies like BEA XMLBeans ( http://dev2dev.bea.com/technologies/ xmlbeans/index.jsp) are starting to change the productivity trade-off that developers are normally forced to make. XMLBeans allow you to easily access XML data directly using XQuery and an XML cursor, but also automatically build Java "views" on your XML data based on information provided by XML Schema. This allows you to have the convenience of accessing data using a Java programming model, but with all the constraints of the data model defined by XML Schema still in force, and the inherent extensibility of XML always available to you. Similarly, the ECMA group has been working to make XML a first-class citizen in the JavaScript programming language (www.ecma-international.org/news /ECMA%20E4X%20Final%20Final.pdf), and rumors abound that Microsoft has a similar initiative in the works with X#.

With tools like these, developers can start to think seriously about using XML Schema and XML as the center of the data model of an application, not just as a translation that happens at the outside. To be clear, it's always important to have some translation layer at the edge of your application to ensure loose coupling between the internal data model and the public data, but there is no reason this has to be a translation between XML and objects. If XML is used as the internal data model, it can be a simple XML-XML transformation, for which there are many tools and languages available.

So in the next application you write, consider using XML at the center. If you are building an application that does a lot of XML processing, I think you'll find that using some of the new technologies for accessing XML gives you the same productivity you'd expect, and saves you from the tedious translation and validation code you're normally forced to write. I think we'll see XML permeating application development more and more over the coming years, and a whole set of new tools and technologies being developed to unite relational, object-oriented, and XML data even more over time.