© 2003 International Business Machines Corporation. All rights reserved.
Q: First of all, let me congratulate you on being named an IBM Fellow for all of your well-deserved work on database languages. I think most of our readers are familiar that you are one of the founding fathers of SQL. Was it a natural extension for you to move your focus from relational to XQuery, or was there some adjustment you needed to make?
A: Thanks very much! Actually, my work at IBM has had two major threads: databases and documents. I was privileged to work with Ted Codd and to be involved in the early relational database work that led to SQL and DB2. Then I spent several years working on editing and formatting of structured documents, using a notation called SGML that was a predecessor to XML. In the past few years, the World Wide Web has brought the two worlds of documents and databases together. So I feel that my work on XQuery is the natural culmination of the interests that I have been pursuing throughout my working life.
Q: What is it like to be a member of the XML Query working group?
A: It's a big job! The working group has about forty members, representing about 25 different companies. Their backgrounds range from relational databases to library science. Some are theoreticians, some are pragmatists, and several are designers of other query languages. We have regular weekly conference calls, face-to-face meetings about every six weeks, and we exchange hundreds of emails every month. If you can imagine trying to design a complex language, constrained by interfaces to several existing languages, in a room with 25 smart and opinionated people, you can image how much fun we're having, and why the process is taking such a long time.
Q: What is the current status of the XML Query standard? When can people expect a stable specification to build against?
A: As you know, XQuery is described by a set of working drafts that are linked from the Query Working Group web page. These working drafts provide an overview of the language and describe various aspects such as the data model, the function library, rules for static type-checking, etc. So far, two of these working drafts have entered "Last Call" status, which means that the public is given a limited period of time to submit comments and raise issues relating to the document. I think it's reasonable to expect the remaining parts of the XQuery specification to enter "Last Call" status before the end of 2003.
The World Wide Web Consortium (W3C) has a very structured process for creating a standard, which it calls a Recommendation. After all the issues raised during Last Call have been addressed, XQuery will be eligible to advance to a Candidate Recommendation. Then, when at least two interoperable implementations have been demonstrated, it will be eligible to be a Proposed Recommendation. The W3C Director makes the final decision to adopt a new Recommendation. This process usually takes a few months. Since XQuery is a complex language that interacts strongly with several other W3C Recommendations, its approval process will probably take longer than usual. We are trying to speed up the process as best we can by coordinating with other W3C working groups, including Schema and XSLT.
Q: Sounds like it might be a while?
A: No, all this doesn't mean that implementors will or must wait for a final W3C Recommendation before implementing XQuery. Some parts of the specification are now reasonably stable. Several early implementations of the language have already appeared, and some of them have links on the XML Query web page I mentioned. Vendors who implement the language before the specifications are completely stable are taking a risk that they may need to make some changes when new working drafts appear.
Q: Assuming that most of our readers are familiar with SQL and the relational data model, what kinds of language changes can they expect to see to accommodate XML data?
A: The relational data model evolved in the world of structured business data, where information tends to be regular and homogeneous. This allows "metadata"--the data that describes the data--to be factored out and stored in a separate catalog. XML, on the other hand, evolved in the publishing world, where every document has a different structure, and each piece of data needs to be self-describing. In XML, the metadata is distributed throughout the document in the form of tags. This means that the operators of XQuery need to be very flexible because they don't know exactly what they are going to encounter. For example, in SQL, the expression "salary + bonus" always adds one salary-value to one bonus-value. But in XQuery, the same expression may be applied to an XML element that has zero salaries, or many bonuses. Designing a language for the very flexible and dynamic environment of XML has been a big challenge.
Another important difference between relational data and XML data is that XML data has an intrinsic ordering that is not derived from its values. Again, this is because XML has its roots as a document markup language, and the contents of a document have a natural order. The notion of ordering is basic to XML and affects many of the operators of XQuery.
Q: How does XQuery differ from the work being done in ANSI on SQL/XML?
A: SQL is a relational query language, designed for operating on tables with rows and columns. The SQL/XML work in ANSI is designed to extend SQL to provide certain XML-related features. For example, these extensions will allow XML data to be stored in a column of a table, and will allow results of relational queries to be delivered in an XML format. But the fact remains that these are just some new features added to a fundamentally relational language.
XQuery, on the other hand, is a completely new language designed from the ground up for operating on XML data. XQuery doesn't understand anything about rows and columns. It is based on the type system of XML Schema, which is quite different from the relational data model. XQuery uses two-valued logic rather than three-valued logic as in SQL. Many of the operators of XQuery are inherited from XPath, which causes them to behave differently from the operators of SQL. For example, the "equals" operator in XQuery operates on sequences of values, and returns "true" if any member of the left-hand sequence is equal to any member of the right-hand sequence.
Q: When can we expect to see XQuery being supported in IBM products, such as DB2® Universal DatabaseTM, and DB2 Information Integrator?
A: IBM has already released XML for Tables on alphaWorks®. XML for Tables is a technology preview of XQuery capability on top of DB2 UDB. In the future, IBM plans to build XQuery capabilities directly into DB2 UDB and DB2 Information Integrator.
Q: Everyone loves your book on DB2 Universal Database . Can we expect to see a book from you in the future about XQuery?
A: Thanks for asking! It happens that just this month (August 2003), Addison-Wesley will publish a book entitled XQuery from the Experts, containing chapters written by ten members of the XML Query working group. My chapter is called "Influences on the Design of XQuery." I've tried to explain how the XQuery design evolved by examining eight controversial "watershed issues" that had a big influence on the language. One of the other chapters is a language tutorial. Each of the participating authors brings a different perspective to describing XQuery, and I think the result gives a very good overview of the language.
Q: What do you plan to do after XQuery is finished?
A: XQuery Version 1 will lack several important features, including an update capability, full-text search, and a facility for recovering from errors. We just didn't have enough time to address these issues in our first try. I expect that there will be a follow-on, called Version 1.1 or Version 2, that adds these and other features to the language. I enjoy working with the people in the XML Query working group, and I look forward to participating in the future evolution of XQuery.
In the long view, these are very exciting times to be working in the information retrieval field. The Web has made all kinds of information available everywhere, all the time. This is a revolutionary development and its impact is just beginning to be realized. Finding ways to organize and exploit this wealth of information is going to keep tool-builders like me busy for a long time.
Q: Thanks very much for your time, Don, and I'm looking forward to hearing your Webcast on September 3rd, 2003.
A: Thanks for inviting me!
All statements regarding IBM's future direction or intent are subject to change without notice, and represent goals and objectives only.
Don Chamberlin is well known as one of the primary designers of the SQL database language. He works at IBM's Almaden Research Center, where he specializes in database languages, database systems, and document processing. He was named an ACM Fellow in 1994, and was elected to the National Academy of Engineering in 1997, the top honor in the engineering profession. He recently became an IBM Fellow for his work on relational database languages. Currently, he represents IBM in the W3C XML Query Working Group and is an editor of several working drafts on the XQuery language.
Comments (Undergoing maintenance)
Table of contents
Local resources
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
