Extensible Markup Language (XML) is quickly becoming the de facto standard for exchanging corporate data via structured documents--whether internally, with business partners, or via public applications across the Internet. However, the data you need to exchange will likely be stored today in a relational database or some other data format rather than in an XML document. Therefore, you need to implement a process to translate data from its current format into XML and from XML back to the formats you use internally to process data.
You could use some of the tools that are available with relational databases such as Oracle's Oracle9i and IBM's DB2. These tools can translate structured and even unstructured data to and from XML. However, if you use these tools to translate data on-the-fly when an XML exchange is requested, you may actually increase the processing time of XML-based transactions as well as potentially slow other applications that might be accessing the relational database.
Alternatively, you might consider another approach--native XML databases. These databases--relatively new to the marketplace--do not replace your relational databases. Rather, they act as an intermediate cache between your Web applications and your back-end data sources (e.g., relational databases, data stored in file systems) to speed up application performance.
Beyond speed, native XML databases are useful because they provide a standard way to let you translate data from multiple back-end data sources into XML and vice versa. This is an improvement over implementing XML translation techniques for each data source you might have. Thus, all of your applications that need to exchange XML data can use one native XML database to cache XML documents. This will reduce the overall effort needed to manage XML translations.
[an error occurred while processing this directive]
