AN enormous amount of my work revolves around e-mail. I get requests for work, and I get the components of the jobs that I’m working on through e-mail. I send the results of my work and progress reports out through e-mail. A lot of what I do involves receiving e-mail, reacting to it, and either returning it or sending it on.
Much of what I do with e-mail generates more than just e-mail. E-mail turns into appointments in my day book, reference notes, and portions of projects that I’m working on.
Despite the relationship between e-mail and all of the other things that I do, for many years I resisted using a personal information manager on my desktop computer. It seemed sort of pointless to have all of my appointments in my computer when people kept asking about my free time in corridors. A personal digital assistant (first a Palm, now a Handspring Visor) changed my life. I switched over to a personal information manager (Outlook) instead of just an e-mail client and use my PDA to enter and to refer to data when I’m away from my desk.
None of this data is in a database, at least not in any relational database that I can access effectively. This drives me nuts. In the business world, only a small part of the data that a company uses is in a relational database (let alone in the same relational database). The small part of the data that’s machine readable is spread over Word documents, Excel spreadsheets, and e-mail systems, among other systems. This would drive most businesses nuts too, but they’re spending so much time managing their relational databases that they just ignore the non-relational data.
There are basically three potential solutions to the problem. One is to keep all of your data in a single database.
This is Oracle’s strategy, which makes sense if you’ve got more than 35 percent of the database server market (and more than 60 percent of the non-mainframe market). The second alternative is to provide a uniform way to access all possible data stores. This is Microsoft’s strategy, which makes sense if you’ve got less than 20 percent of the database server market. The third alternative is to provide some way of moving data between all possible sources, which is what XML is supposed to do. This makes sense if you’ve got time on your hands.
I don’t want to knock the power of XML, but moving data around so that you can convert and re-convert between data formats is time-consuming and error-prone. There’s also the problem of synchronizing your data. I worked for one company where we were regularly downloading data from a mainframe database to Access databases so that the data could be accessed from the PC-based tools that we were using. Of course, as soon as one transaction was processed on the mainframe after the download, our Access data was out of date. It was a nightmare. I still wake up screaming, and when I do, my wife just says, “It’s the data conversion, isn’t it?”
The problem with the single data access strategy is the format in which the data is returned. Microsoft’s ADO, for instance, returns data in recordsets. It’s a wonderful format, but it doesn’t travel across the Internet well and can’t be processed on any platform except Windows. However, if all of the data came back as XML, then it could travel over the Internet well (it’s just text) and could be processed on any platform (using any of the standard XML processing tools).
Not surprisingly, then, almost every database vendor is providing ways to receive and return XML documents. Microsoft has done this with SQL Server, but it remains to be seen whether similar capabilities will be provided for Jet.
With Access 2002, you can export and import data in XML format from both Jet and SQL Server. That moves you back to the third solution of having a common format for moving data around—not a happy thought. There are also some significant issues around the way that Access 2002 creates its XML documents, which I’ll discuss in an upcoming article in our Access 2002 series.
What’s left to put together now is a universal, platform-independent way to submit requests for data. To a certain extent, there’s even a contender in this area, Java Database Connectivity. However, the goal of the new standard would be to allow a developer in any language to submit a data request from any client on any platform to any type of data manager on any other platform. That request would probably be in some XML format, and the result would have to come back in some standard XML format. The only organization that could establish a standard in this area is, I think, the World Wide Web Consortium. Currently, they’re working on a standard for querying XML documents (XQuery). I think that’s great, and I’ve discussed it in our sister newsletter, XML Developer.
But what I really want is an XML-based tool for querying and updating any data source, not just XML documents.
Christmas is only six months away. I don’t think that it’s too much to ask for.