XML (extensible markup language) is one of those ubiquitous emerging internet technologies that have taken the world by storm [Ref1]. Like HTML before it [Ref2], the XML standard was sorely needed as a way for:

From XML 1.0, the aim of XML was well specified and modest [Ref3]:

"The Extensible Markup Language (XML) is a subset of SGML that is completely described in this document. Its goal is to enable generic SGML to be served, received, and processed on the Web in the way that is now possible with HTML. XML has been designed for ease of implementation and for interoperability with both SGML and HTML."

Back in 1998, there was only a 32 page XML specification [Ref3]. Now four years later, we have a plethora of supporting standards and products [Ref4].

The current standards and topics include:

The history of XML can thus be traced back to the earliest days of mark-up languages in the 1960's. Some of the first forms of mark-up languages included Generalized Mark-Up Language (GML) and Standard Generalized Mark-Up Language (SGML). Both of these languages provided the foundation for Hypertext Mark-Up Language (HTML). One of the specific problems with SGML was that it was so complex or heavy. SGML also required a Document Type Declaration (DTD). Now with the addition of schemas, messaging, queries, and graphics, the promise is much broader. The Geography Markup Language from the OpenGIS consortium is a new but strong entry.

In terms of security, the standards remain disconnected and under development. The W3C has recommendations, working drafts, and notes. We have from W3C:

From Oasis, there are several other connected and emerging specifications:

XML guards, very much like e-mail filters, are under development in a variety of programs [Ref17].

Perhaps the holy grail on the internet is the "semantic web." The basic idea here seems to be to achieve better machine to machine interactions [Ref5]. However, many of the standards in the pipeline to achieve this (such as RDF and UDDI) are too cumbersome and complex to be genuinely useful. For the military, the need is simply to enable joint interoperability and integration.

To achieve this more modest vision, the use of the basic XML standards including

may be sufficient over secure communication channels or networks. Most critical systems will for a very long time have a man in the loop in order to assure accountability and the fulfillment of the commander's intent. However, if we can get the C2 programs to work together better, then the number of men in the loop can be optimized [Ref6].

Why has the web been useful to hundreds of millions worldwide and a model for the development of net centric warfare? Why are web technologies already a part of military and government information systems? The basic reason is that the web is easy to use and it works well. This began with the Internet decades ago and was transformed into the WWW beginning in the mid-1990's. The advent of graphical home pages for individuals, corporations, universities, and government/military agencies helped make the internet into a useful tool for everyone. The success of the personal computer enabled most users to have a low cost device for communicating with internet sites. In terms of bandwidth, there are two trends:

High level individuals in DoD (Department of Defense) at the Pentagon have observed this proliferation of successful and cost effective web technology and wisely want to leverage this huge mass market commercial investment for military use.

The WWW is the content of the Internet, itself a global network of networks. Hundreds of millions of users connect from personal computers, workstations, and other types of computing devices. There are currently millions of web sites, each an information source that is available, usually free of charge.

The WWW is thus a new phenomenon (from the 1990's) with diverse uses:

At the heart of the world wide web is the convergence of key cost and operationally effective technologies:

The leveraging of WWW technologies for military use is sometimes called network centric warfare [Ref16].

There are of course many other parts which fall into these three categories from the browsers (e.g. Netscape Communicator or Microsoft Internet Explorer) that are a popular interface to the web to the protocols and languages like HTML (hypertext markup language) and XML (extensible markup language) that allow the machines to communicate with each other. Today the web is poised for another five years of rapid growth as two main businesses continue to develop:

The realm of COTS tools is where XML has made its biggest mark. Browsers have become XML enabled, databases allow extraction and import of XML files, Office tools understand XML, and military C2 systems are beginning to exchange data in XML [Ref4]. There are many browsers in use but the two most popular are Netscape and Internet Explorer. Both of these in their later versions are able to read XML files and understand CSS style sheets. A browser or an application program makes use of a parser to read and understand XML.

Many XML products already use the World Wide Web Consortium (W3C) document object model (DOM) and/or the xml-dev simple API for XML (SAX). DOM parsers typically load the entire XML document into memory. SAX is a lighter-weight alternative than DOM because it doesn't require resources for this in-memory representation. Both DOM and SAX allow access to XML data via C, C++, Java, BASIC and other languages [Ref1].

The database arena continues to advance in two areas with respect to XML:

Recently, one company, which pioneered a native XML database, closed down. It is unclear if there is sufficient market for native XML databases. The end result may be - as with the object oriented databases of the early 1990's - that blends of the technology are what persists.

Major vendors of database management systems (DBMS) have recognized the advantages of incorporating Extensible Markup Language (XML) into their database storage products. Currently, all of the major database vendors (IBM, Oracle, and Sybase) have integrated or are planning to further integrate XML technology deep into the core of their DBMS. This integration of XML technology has the potential to help solve some of the existing interoperability issues between independent applications and systems [Ref7].

Microsoft SQL Server is a relational database management and analysis system for e-commerce, line-of-business, and data warehousing solutions. Microsoft began to integrate XML components in SQL Server's version 7.0 in 1998. XML for SQL Server is now embedded in the product for the SQL Server 2000 version. Transaction Architecture for the Management of Internet Objects (TAMINO) is an XML platform from Software AG specifically designed to facilitate data exchange between the Tamino XML database and external databases and applications. The Tamino management system stores native XML.

Office tools have been XML enabled as part of the Microsoft .NET initiative. There are also several plug-ins that allow even great XML functionality These COTS plug-ins come from several companies including HV Limited and i4i. According to HV Limited,

"WorX 3.2 includes a brand new WorX Authoring Assistant Framework in Microsoft Word to allow non-technical users to create XML content."

The basics of XML are fairly simple. This is one of XML's great strengths. The hard part is getting the developers of disparate systems to agree on the tag or element names. The current commercial models for coordination (consortia, partnerships, and standardization groups) are all good models for government applications. These agreements, when reached, are captured by an XML document type definition (DTD) or XML schema and/or in the registration of tags in a registry or federation of registries. Ontologies and the mapping of semantic content between programs may also have some utility.

The military has long had message processors as part of C2 systems. Two of these message processors are the CMP and IRIS products. Each system operates independently from each other. Other software modules provide additional functionality for:

The CMP has been used in some of the BFA subsystems that make up ABCS. Systematic Software Engineering is an international software company dedicated to developing software products, providing solutions and delivering services to the defense and commercial markets. Systematic was founded in Denmark in 1995. Systematic has developed a comprehensive message handling and formatting system called IRIS/MFS, which has been successfully introduced into the NATO community and the USAF TBMCS program. The IRIS product is compliant with multiple USMTF and JVMF baselines, and XML.

The implementation of DTDs versus schemas in COTS tools continues to be an issue. We have a table which gives an example of the differences between DTDs, schemas, and other type definition languages [Ref7] [Ref11]. The initial XML specification had only DTDs, so early adopter companies jumped on board that bandwagon. As time goes on and funding allows, many of these are converting to schemas.

XML query languages have also been slow in development and adoption. We have also done an analysis here and a table is available [Ref7] [Ref11]. The impact on connecting and querying XML documents and databases is thus still unclear.

The U.S. military structure is divided in a number of ways, some obvious by service like

and others doctrine and technology based such as

A further division may be made in terms of mission or functional areas. For example, one might divide up the components of a C2 system into subsystems including

Very often, the computers and the networks/radios are looked at as "to be added" infrastructure, but the acquisition of software and hardware needs to be intimately related. If this is done right, then we can have NCW with an effective future system of systems.

Typically, in determining how a system or collection of systems works (or doesn't work), the developer focuses on a very specific thread. Some examples are:

Thus a question might be asked such as: how is the MTI information passed in messages or XML from one system or platform to another? There must be an end to end way of doing this in order to most effectively utilize that information.

Now, the fighting of a war is inherently a joint and multinational/coalition endeavor. Thus, U.S. systems need to interoperate to some extent with systems from other countries such as Britain or Australia, for example.

Although many examples of both traditional messaging and XML use are possible, here we focus on the OPORD or operational order. The ATO has been discussed elsewhere [Ref7].

All OPORDs contain a five paragraph base order. The base order has parts for the situation and other areas. In JVMF, the limitation is typically to the number of bits per paragraph. This is supplemented by annexes and appendices, the number of which depends on particular commanders and operations. Some typical Army annex examples involve the task organization and other areas. In the JVMF standard, the annexes are somewhat different from what the Army uses. XML allows these methods to be connected.

OPORDs used in recent exercises have been developed in Microsoft Word, Excel, and Powerpoint formats. File sizes range up to several MB, but are typically less than 100 kB. When zipped, the typical 100 kB file reduces in size to 10 kB. The Word formatting, Excel expression of matrices, and Powerpoint capability with graphics are extremely useful to the warfighter. These capabilities are achievable via the transfer of compressed XML. This creation, transport, and display process (in XML) is the subject of intense investigation in current and future systems' development.

Here we just give an example of the tags and structure used in two prototype efforts. The below table summarizes some of the element names. The actual names are not important, but the point is that different developers will choose both different element names and different schema formats if there are no core XML elements to be used.

The reconciliation of tags and structure cross programs and services is an ongoing effort. The structure is more revealing if shown graphically and in detail [Ref7].

Within a system of systems of any particular service (say the Army as an example), there is thus a need for interoperability with other:

How is this information exchange achieved today? The data is exchanged in several ways

How might this information exchange be better achieved in the future? Of course, there will always be a need for some human exchange. Certainly, human to human voice interaction and human to machine control will always remain. However, much of the information exchange can all move to the XML format to either better enable the human to machine interaction or to more fully automate certain exchanges.

For example, there are several legacy messaging formats:

As a first step, all of these legacy formats have been XML enabled. This is only the first step because the harder work is figuring out how to reduce the number of messages and data elements that are in use and exchange missing information via XML.

Within any of these messaging standards and yearly baselines, a variety of messages are an interface between any pair of systems. For example, select messages of interest may include:

These messages may be similar, but are not the same in every different military messaging format. XML can be used to drive these diverse stovepipe formats to a more useful core set.

In the same way, there are several legacy data schemas in use:

Again, as a first step, many of the elements of these legacy databases have been XML converted. Thus, a particular row and column of the database has at least an XML name and DTD or schema type. This is only a first step because the harder job is connecting the databases and reducing the number of file extractions and data elements. Also, to pass and receive needed information that is not currently being provided in a future publish-subscribe environment.

Current and in development systems are thus constrained to have both messaging and database interfaces. In the USAF, all systems are directed to also have an XML interface. Again, this is just a first step because what needs to be done is to reduce the number of pairwise interfaces. Exposing them in XML is the beginning.

XML files that are needed system to system can then be shared in a publish-subscribe environment. There are many ways to achieve this. The shared XML files can be in a repository accessible via a tactical network, pushed to users, or pulled by them as needed.

The US Message Text Format (USMTF) is the standard format used by the joint forces to exchange information (e.g. between ABCS and TBMCS). This standard provides a way of defining messages. The XML-MTF team has created XML-MTF schema and document specifications for use by the US military and joint forces [Ref8]. The result of this effort will be reflected in the USMTF baseline 2002 and NATO ADatP3 baseline 12 (the NATO members USMTF-like message standard).

A Joint Variable Message Format (JVMF) is implemented as a binary message. It is used to exchange information between units in the upper echelon and units below. Bandwidth and data presentation limitations have been unresolved issues in the JVMF community, but improvements in communications infrastructure are planned for this decade (JTRS etc.). The introduction of XML technologies into the Army opens new alternatives to resolve some of these issues. With XML, it is possible to create element names and element structures that match every element and structure defined in the JVMF specification; in fact this is what the XML-VMF development team has done [Ref8].

With respect to future systems, interoperability and integration is key [Ref9]. Not surprisingly, there is a certain amount of politics involved as well. For example, in order to try to better ensure future interoperability, OSD has issued a document called MID912 [Ref12] which aims to achieve many important interoperability and integration goals.

How difficult is the management of interfaces in system development? To get an idea of the complexity of the problem, consider the following systems. These are not exactly real systems, but the numbers are representative.

Now, for just one of these system interfaces, say between an Army and a USMC or USAF system there is also then a requirement to connect in a variety of ways:

Thus, just one interface can mean that you have to worry about (numbers are notional and examples only) 8 JVMF, 10 USMTF messages, and database transfers between 3 dbs. Since every message standard has a yearly baseline and databases are controlled less well, we end up with an expensive and complicated configuration control problem. This is why the PEO/DACs are issuing directives and guidance to use XML interfaces, which are more open and flexible [Ref12].

Another area where XML web services is poised to impact the military is in the test and evaluation area. The Test and Training Enabling Architecture (TENA) that is part of the CTEIP (Central Test and Evaluation Investment Program) and JDEP (Joint Distributed Engineering Plant) programs is of interest in this regard [Ref13] [Ref14] [Ref15]. Web services have strong applicability to pre-exercise packages, run-time applications, and product improvements [Ref15]. The use of XML in system development promotes interoperability, can save money in system deployment, and can reduce training time.

In developing the system, the main focus is then not necessarily on the components, but rather on the interfaces and the information exchange. Yes, someone must determine what the components or subsystems are. Yes, it would be nice if some of the parts had at least a common look and feel. But it is critical that each functional application:

Even commercially, this has been hard to do mainly because the pieces of good software (word processor, spreadsheet, presentation tool, database) were typically built by one company and acquired by another. Over time, the pieces of office tools fit better together, but this success was achieved on the backs of millions of users. Web services aim to bring this type of interoperability to the programs that have smaller numbers of users as well as the mass market products.

Before XML and web services, integration was fairly difficult and expensive occurring either at data, application, or process levels. Various kinds of brokers and adapters have been used in the integration. This integration broker approach basically preserved stovepipes in military and commercial systems because of the high cost, limited return on investment, complexity of implementation, and lack of standards. Brokerless integration makes use of more intelligent adapters that connect into existing applications.

Several vendors are involved in the integration market, including Microsoft, IBM, Sun, BEA, and TIBCO. The web services interoperability organization aims to ensure that there is interoperability cross platforms, e.g. from .NET to J2EE and back [Ref10]. According to WS-I.org: "WS-I is an open, industry organization chartered to promote Web services interoperability across platforms, operating systems, and programming languages." The idea is that although the standards are important, they are not sufficient; real testing of applications and code is needed.

XML and web services thus enable a paradigm shift in integration and interoperability. Rather than managing hundreds of pairwise interfaces and literally thousands of types of specific information that is exchanged, it is now possible to move to a publish-subscribe environment where the information is made available in XML for appropriate users. Think of a bus rather than point to point wire design. If this approach more fully penetrates military and commercial software development, interoperability and the user will be winners.