XML is a hot topic these days, but what can XML really do for your company, and should you deploy it? Understanding what this standard can do for you is only the first step in an evaluation. The next step is deciding if you should use it. These pros and cons of deploying XML in your solutions can help you make the decision.

How XML can be used
XML is an excellent tool for describing centralized data that will be displayed or used by an application. Because most Web-based applications are built with a focus on data, XML has evolved into the standard for Web services.

You can use XML in your enterprise on a number of levels. Locally, XML is often used to store content that will appear on a Web site. You may also use it as an internal repository for information that will be accessed by custom or third-party applications, when the relational capabilities of a database are not required.

Moving from internal to external applications, XML makes it possible for you and a vendor or other partner to exchange data in a mutually agreed-upon format. You can each maintain your own closed, proprietary systems without having to take into account the architecture of your partner’s systems.

The advantages of adopting XML
The main reason many enterprises have adopted XML is because it allows for facilitated integration with outside vendors or partners. You may have three different vendors, all with proprietary systems that require access to the same data. XML allows you to present data in one format, while all three vendors can read the information and use it as appropriate for them.

Obviously, XML’s popularity is justified by its ease of use and timesaving centralization of information.

Under the right circumstances, there are other advantages to using XML. When dealing with Web applications, containing your content in an XML file that is then parsed by your application can greatly facilitate content maintenance. Instead of changing menus, page titles, content, etc., in several places, the changes can be made globally by editing one XML file.

XML can also be used to easily extend both the content itself and the type of content that is stored in the file. While it may take a system longer to open a file than to access a database, processing time is shortened if only relevant information is stored in the file You’ll have to perform searches and sorts using functions within your programming language instead of the functions contained in your database. But, generally speaking, XML content is intended to be displayed, and such processing may not be required.

Another great benefit is that you can easily include only the subset of data that is relevant, physically prohibiting system access to information that won’t be used.

The disadvantages of using XML
Of course, every silver lining has a cloud, and there are some limitations that may make you think twice before deploying this standard. For one, XML can make very large data sets unwieldy to maintain. For this reason, it is popular to maintain information in a database and then output the relevant data into XML. In this case, you’re not actually maintaining information in the XML file—you’re merely preparing it for presentation. This formatting process may or may not be seen as a disadvantage, but it is a consideration.

One definite disadvantage, however, is the lack of integrated security. A shared XML file is automatically processed by the requestor (the recipient) of the file. If, however, you have encrypted the file to ensure security, the receiving parser won’t automatically recognize it. There are several XML security standards on the horizon that will address these and other issues, but a standard has not yet been set.

As such, a company may need to limit distribution of files to a VPN or extranet, or else run the risk of making the information contained within the XML file readily available to anyone on the Internet that knows where to look.

Access control also presents a fairly large issue in itself. Until the standard has been implemented, the only reliable means of providing different subsets of your information to different people is to create separate XML files for each variation. If you are trying to use XML as an integral part of your enterprise B2B solution and need customized access for each party, you’re probably better off using stored procedures in a database to limit access than to attempt to manage a large number of XML files.

How to decide
When considering XML, think about what you are trying to accomplish that using XML would facilitate. Are you trying to transmit the same, relatively nonsensitive information to several vendors that each use different software on their end? If so, XML is a good choice. Do you want to easily maintain your Web site without having to rely on a database back end? Again, implement XML.

However, if you are dealing with sensitive data, or distributing different portions of your data to different applications, you may want to hold off until further security standards have been implemented. Essentially, if your solution includes the creation of multiple XML documents for similar services, you may be jumping the gun a bit and creating a maintenance nightmare.

For local applications, you may need to weigh the particulars of each implementation. If security and access are not issues, determine whether centralizing your information in an XML source would be beneficial on a case-by-case basis. If you need the data for display only, and it appears in multiple places, then it’s a great candidate for Web services.

Riding the bandwagon
If you’re ready to explore the possibilities of XML, consider the type of information you’ll be working with and the scope in which you’ll be working to help decide whether this is a good solution for you. If there is a definite gain to be had and you don’t mind tweaking your solution until security standards are finalized, then proceed carefully and intelligently. Otherwise, you may want to let others blaze the trail first, and follow when the time is right for your solution.