This is not really design issues - it is market positioing.
For some, the whole Semantic Web effort can be summed up as a general solutoin for this problem. Huge amounts of effort are involved every year in making custom connectoin between different applicatoins within an organization. The stock controil system can generate information for the accounting system; the payrole and the phone book could be connected to save rekeying. And so on.
The semantic web vision for a universal information space solves this in the same way that the Web solves the documentation system integration problem.
Think back to before the Web, in 1989. There were many documentation systems. They used different software, and ran on different machines, using differnt networks. You often had to use different types of terminal to get to them. Consider the task of getting information from one to another. In the lucky case in which from the same computer you could connect to two different documentation systems, you would still have to fight your way through telent connectoins and isfferent programs, get hte data displayed, then copy it onto the pasteboard, and go into a new series of telnet connections and programs on anohter machine, until a form appeared into which you could paste the data. Alternatively, you could use one of many third party products which were written to convert data from one system to the other. (I wrote one for example to move user help information from an IBM mainframe system to a VAX/VMS HELP system. Since then, the web has made that problem seem like ancient history. The same documentation system still exist in all their diversity, but each has a small shim of software which makes it appear as part of the seamless Web.
Now consider what happens in 2001 with the data in your life.
When it comes to data, we are pre-Web.
Isn't XML
Just the operation of merging data from two applications in RDF is trivial, and in XML is undefined. There is no answer for what the merge of two XML documents is.
@@@