In my last column ("SQL3 Moves Forward," June 1998), I told you that the final Committee Draft (CD) ballot for SQL3 had recently closed and that an Editing Meeting was scheduled for three weeks in March and April. To refresh your memory: Four parts of SQL3--Framework, Foundation, PSM, and Bindings--were submitted for an FCD ballot that started in December of last year and closed in February. Those ballots produced 1,545 comments from eight countries, of which 524 were categorized as Major Technical. An Editing Meeting was held in Curitiba, Brazil, to address those comments.
I indicated in that column that I no longer believed that SQL3 would be published in 1998 and that I had concluded that a third round of Editing Meeting would be required to address the rather large number of comments submitted on that ballot. The participants in the Curitiba round of the Editing Meeting agreed with this conclusion and have tentatively (pending approval in July by the new ISO/IEC JTC1 subcommittee SC32) scheduled a third and (we hope) final round of this Editing Meeting to be held in the first week of November. More on this shortly.
The meeting in Brazil was the first SQL standards meeting ever held that ran for three weeks. When I first got involved in the ISO SQL activities, meetings lasted for one week and a typical meeting day started at 9:00 in the morning and ended at 5:00 in the afternoon, often with a fairly leisurely lunch. Of course, there might have been as many as 40 or 50 technical papers to consider during that week.
Several years ago, the meetings grew to two weeks each and the workdays lengthened gradually until some recent meetings had us starting at 8:30 in the morning and sometimes working past 9:00 in the evening. This was due in no small part to the fact that our proposal load had increased to more than 200 papers in a single meeting (one infamous meeting had almost 300 papers to be addressed), as well as the increased complexity and controversial aspects of the subjects handled.
Well, the trend continues! The Curitiba meeting may have had "only" 160 or so papers to cover, but we knew going in that there would be so many comments submitted on the ballots that we couldn't get by with a mere two weeks. A three-week meeting is hard! (I feel great sympathy for the guys who had to stay for yet another week to attend the SQL/MM meeting that followed the SQL meeting.)
The meeting was hosted by Vilhanova Orténcio, the Brazilian delegate to the group. Knowing that we had a huge workload and were going to be away from home for a rather long period, Orténcio arranged several stress-reducing weekend activities, such as a bus tour of the city, a train ride to a coastal town known for its serenity and food, and even a barbecue at a country cottage (a chýcara) that he owns in the mountains nearby Curitiba. (No, this column isn't going to turn into a travelogue, but I thought you'd be interested in some of the arrangements.) The benefits of having such good care taken of us certainly made the three weeks go just a little bit easier.
In spite of, or perhaps because of, all the fun we managed to have in our off-hours while in Curitiba, we accomplished significantly more than I would have predicted. Of the 1,545 comments submitted on the FCD ballots for the four parts of SQL, we resolved a full 1,003 of them. Of course, this process was eased considerably by the fact that all the Minor Editorial comments (170) and not a few of the others were simply designated to be the Editor's responsibility. I don't mind telling you that I spent quite a few late nights trying to get the editing started by taking care of many of those assignments on the spot.
This prodigious accomplishment leaves us with 563 comments remaining open. (Yes, I recognize that 1,545 minus 1,003 is only 542, not 563. However, we discovered a few more problems--21, to be precise--and added them to the list.) Of these, there are still 288 Major Technical problems and 217 Minor Technical ones (as well as 50 Major Editorial and eight Minor Editorial).
As you would expect in a Final CD Editing Meeting, great pains were taken not to introduce any new features to the language. In fact, several (minor) features were taken out of SQL3 because they were proving to be too difficult to get completely debugged (that is, to address all the comments involving them) and the credo of "smaller and faster" was being taken seriously. In other words, we're very sensitive to the fact that SQL3 is running much later than intended, and we're willing to shed marginal capabilities in order to accelerate the schedule as much as we can.
Instead, we focused heavily on the "theme features" of SQL3, such as the object-oriented capabilities about which I've written for so long. As we expected, there were considerable numbers of comments (outlined in my June column) in this area and everybody pitched in to resolve as many of them as possible. While we made a lot of progress, there are quite a few comments left to handle.
The remaining problems are concentrated into a few primary areas:
• Clarity of specification. Many comments identify the need for more precise terminology and language, as well as uniformity of language used to define similar concepts in different parts of the documents.
• Refine Core SQL definition. The precise contents of Core SQL (the minimal language for which formal conformance can be claimed) are still under debate with the expected tension between implementers, who naturally want less, and users, who naturally want more.
• Object-oriented features. We're still refining the SQL3 object model (and I discuss this further below), particularly the exact functionality to be provided with reference types. There are also a number of issues related to SQL3's ability to support "shrink-wrapped" type libraries and software components.
• Privileges and security model. We accomplished a significant cleanup of the SQL3 specification of roles at the Curitiba round of the Editing Meeting (largely due to a series of Italian proposals), but interactions between these and other papers inevitably introduced inconsistencies that have to be identified and resolved.
• Dynamic SQL and embedded SQL. A number of comments identify problems with the way that dynamic SQL is specified, mostly complexity of the rules, and with inconsistencies and missing specifications for mapping (the newer) SQL data type to host language data types for embedded SQL use.
It's somewhat comforting that the number of major areas in which significant numbers of problems remain has been reduced a bit. Still, I don't want to imply that we're ready to relax! There are some really tough issues left to handle--some technically problematic, others politically difficult.
Unfortunately, the very short time span between the end of the Curitiba round and the start of the Brisbane, Australia round (early April and mid-June, respectively) makes it difficult for participants to develop many change proposals to resolve additional comments, and the difficult nature of many of the comments exacerbates that problem. This suggests that a significant portion of our days in Brisbane for three weeks will be spent writing change proposals.
I have very mixed feelings about how work on the object model is progressing. While I like the fact that we're all interested in having SQL3's object model become much closer to Java's, I am disturbed by the fact that we're making some rather significant changes to SQL3's basic capabilities at what I can only call the last minute.
If you've been following the SQL3 saga for several years, you've seen several dramatic changes in its object model. Most recently, Java has captured the minds and hearts (and, not incidentally, the pocketbooks) of the computer community, so there has been great interest in aligning the SQL3 object model with Java's model wherever possible and meaningful. I suppose one could argue that publishing SQL3 a couple of years earlier might have let its object model dominate the discussions instead of Java's, but most of us don't really believe that SQL would have been as pervasive outside of the database arena as Java has become. By contrast, some observers think it's fortunate that SQL3's publication has been delayed because the delay allows the possibility of adapting its model to Java's; otherwise, having a database language with a significantly different object model than the one taking over the programming world would have probably made SQL even less relevant than it already is becoming.
Let's look at how the SQL object model is being changed for alignment with Java.
One of the most important areas of alignment is in routine invocation--or, more precisely, in "routine resolution." In the 1996 SQL/PSM standard, you can define more than one function (or procedure, but I'll focus on functions here for simplicity) with the same name--this provides polymorphism. The specific function invoked at runtime for a routine invocation, say F(X), depends not only on the name of the function ("F" in this example), but also on the number of arguments and the data types of each of those arguments. Because PSM-96 didn't have to deal with the notion of a type hierarchy--subtypes and supertypes don't exist in SQL-92, which PSM-96 was designed to support--the rules for resolving a function resolution were relatively straightforward, while still providing rich polymorphism. However, PSM-96 used a "generalized dispatch" model, which means that the data type of every argument of a function invocation is used to identify the exact function to be invoked. When a type hierarchy is added to the mix, it becomes impossible to resolve some routine invocations completely at compilation time; if an argument of a function invocation is some type that has subtypes, then the most specific type of that argument often cannot be determined until run time--that is, some aspects of routine resolution have to be deferred until run time, introducing some interesting performance problems, especially in distributed systems.
By contrast, Java uses a "classical dispatch" model in which only a single "distinguished" argument's runtime type is used for polymorphism resolution, while the compile-time types of all other arguments are used. This restriction makes it easier to implement polymorphism in a distributed environment, not least because an implementation can more readily identify exactly where to "find" all candidate routines at run time. However, maintaining compatibility with PSM-96 limited the options for changing the routine invocation model, so we kept PSM-96-style "functions" with generalized dispatch for use only when no arguments are of types that participate in a type hierarchy, and we introduced a new sort of routine--called a "method"--that always has a single distinguished argument. That distinguished argument has a data type that (possibly) participates in a type hierarchy--meaning that it is a user-defined type--and therefore all candidate routines for any given routine resolution are somehow "associated" with that user-defined type.
The model for methods, as you probably know from what I've said so far, is carefully designed to be as close to Java's model as possible. However, it's important for you to realize that Java and SQL differ in one extremely important aspect that significantly complicates SQL's life: SQL has persistence in both data and metadata, while Java has to deal only with individual compilation units and the objects that are "declared" when they are compiled. (Java provides "introspection" capabilities that let Java programs "discover" new object classes at run time, but this still differs significantly from issues related to SQL's persistent metadata, such as schema changes.) This change has both good and bad implications: The good, of course, is that you can use Java and SQL more easily together; but the bad is that significant changes are being made to the SQL3 specifications without adequate opportunity to review and debug the changes before we're publishing the result. Overall, I believe that these changes will be positive for the application development community, but it's going to be a rocky road (as if "Web time" hasn't made things tough enough already).
Obviously, this isn't the only change being made to SQL to make it more Java-like. Another change (which I won't discuss in detail here) deals with the issue of multiple inheritance. SQL3 has long had complete multiple inheritance capabilities; that is, subtypes could be defined to inherit all aspects of multiple parent supertypes. Java, by contrast, has single inheritance of implementation and multiple inheritance of interface. SQL3's designers have done a great job of building full encapsulation into its user-defined type facilities that some of us have argued that its multiple inheritance can by definition inherit only the interfaces. Unfortunately, that turned out to be not quite true; the functions (now "the methods") that implement the user-defined types' behaviors are inherited with not only their signatures, but also with their code--the implementations. Based on this understanding, some of the most active participants reached an agreement very recently to limit SQL3's user-defined types to single inheritance like Java's with the further agreement that a Java-style "interface" definition will be added in the future (SQL4, anyone?) along with multiple inheritance of those interfaces. This will make it significantly easier for application developers to exchange data between Java and SQL almost seamlessly.
Before you get to read this column, the second round of the SQL3 Final CD Editing Meetings will have already been held in Brisbane, and we'll know how successful the participants have been in resolving additional comments. My prediction is that the Brisbane round will complete with fewer than 100 comments remaining open. I mentioned earlier that a third round has been tentatively scheduled for early November; the time span between the end of the Brisbane round and the November continuation should allow for sufficient review and proposal writing that we can complete our work and be able to publish SQL3 (four parts of it, at least) in mid-1999. Whew--at least we dodged the Year 2000 problem!
Jim Melton is senior architect for standards at Sybase and editor of the ANSI and ISO
SQL-92, CLI-95, PSM-96, and emerging SQL3 standards. You can reach him via
email at jim.melton@sybase.com.