Response to the ODMG-93 Commentary Written by Dr. Won Kim of UniSQL, Inc. Object Database Management Group 13504 Clinton Place Burnsville, Minnesota 55337 USA In the March 1994 issue of the ACM SIGMOD Record, Dr. Won Kim of UniSQL and the SIGMOD Chairperson published "Observations on the ODMG-93 Proposal for Object-Oriented Database Language" (Volume 23, Number 1). This commentary contained some useful technical contributions. We thank Dr. Kim for that. Nevertheless, it also contained a number of inaccuracies and misleading statements that we, the ODMG, would like to set straight. 1. Corrections and Clarification Quotations from Dr. Kim's commentary are shown in italics; they appear in the same order as Dr. Kim's commentary. Our comments either correct or clarify issues he raised. We start with his summary of the ODMG-93 specification. Despite its hasty claim, it is NOT a "standard". The membership of the ODMG that has committed to implementing ODMG-93 represents nearly 90 percent of the 1993 ODBMS market and more than 80 percent of the 1993 ODBMS and object relational DBMS market, according to the International Data Corporation (IDC). It is therefore an industry de- facto standard at the very least. The category of object relational DBMS used by IDC includes products such as UniSQL and HP OpenODB. More will be discussed on the related topic of a "formal standards body" later in this paper. Rather, it is a work-in-progress proposal for an object-oriented database language and language bindings to it for C++ and Smalltalk. ODMG-93 is a work in progress. We say so explicitly in the first sentence of the second paragraph in the preface of the book. Dr. Kim, however, seems to minimize the fact that ODMG-93 includes an Object Model, an Object Definition Language (ODL) , and an Object Query Language (OQL) in addition to the C++ and Smalltalk language bindings. The ODL is synonymous with the traditional Data Definition Language (DDL). The language bindings are used for the Data Manipulation Language (DML). This will be discussed at more length later in this paper in reference to SQL. Since ODMG-93 was published in the fall of 1993 we have received excellent feedback as part of the work-in-progress process. This has allowed us to improve ODMG-93. Release 1.1 of ODMG-93 has been recently published by Morgan Kaufmann Publishers. ODMG is not a formal "standards" body. It is a committee formed by five vendors of first-generation object-oriented database systems (OODB). ODMG is not an ANSI or ISO standards body if that is what "formal" means here and we have made no claims as such. ANSI and ISO are "accredited" bodies. Are we a standards body? Absolutely. Virtually every successful standard has originated not from the accredited bodies but from vendors or consortia of vendors, only later to be codified by the accredited bodies. Examples include SQL, SQLAccess Group (SAG), and more recent work in object technology from OMG. In fact, ODMG was modeledintentionally after the multi-vendor cooperation of the SQL Access Group, whose work is now moving through accreditation bodies such as ISO (RDA) and products such as Microsoft's ODBC, as well as all the vendors' products. Additionally, the commitment to implementing ODMG-93 in 1995 has been made by vendors representing over 80 percent of the market represents an industry standard. In contrast, note for example, that ANSI X3H2 membership carries no commitment to implement the specification. The "five vendors" in the second sentence is wrong and implies a limited ODMG membership. The original release of ODMG-93 lists five primary authors on the cover, but on page 7, four others who wrote portions of the book are credited along with an additional eleven industry and academic reviewers. The term "first generation" also in the second sentence is undefined. Our guess is that UniSQL must describe itself as "second generation." We are not aware of any industry definitions of "first" and "second" generation. For several years,some of these vendors have offered products that are not much more than persistent storage managers for object-oriented programming languages, but the misleading label "Object-Oriented Database System" has been stuck on such products in the market. All the member ODBMS vendors meet the definition of an ODBMS provided at length on pages 2 and 3 of the book. There is nothing misleading about this. And now themisleading label "standard" seems to be attached to the ODMG-93 work-in-progress proposals. Again, there is nothing misleading about the ODMG position that the ODBMS vendor commitment to meet the ODMG-93 specifications in 1995 is, at minimum, an industry standard. ODMG member companies represent over 80 percent of the market. In essence, the database language proposal is an Object SQL. This claim by Dr. Kim is not accurate nor have we made this claim. The ODMG-93 query language is the Object Query Language (OQL) and uses syntax similar to SQL. Some capabilities of SQL are subsumed by the ODMG language bindings. Unlike relational DBMSs, ODBMS data manipula- tion languages (DMLs) are tailored to specific application programming languages, in order to provide a single, integrated environment for programming and data manipulation. The major problems and deficiencies in the ODMG- 93 database language are due to the fact that the database language does not subsume the facilities in SQL(despite the fact that the data model on which the database language is based, the Core Object Model espoused by the Object Management Group (OMG), fully subsumes the relational model). This compounds the earlier inaccurate "Object SQL" statement by Dr. Kim. What is inaccurate is the implicit assumption on his part that everything needs to be done in SQL and if it isn't done that way it is "deficient". We disagree. In this part of his commentary, Dr. Kim goes on to discuss views, dynamic schema changes, and access authorization which we will cover later in this paper as part of the technical contributions from Dr. Kim. The goal of ODMG, with respect to the database language (but not the language bindings for C++ and Smalltalk), is largely identical to that of the X3H2 Database Standards Committee (i.e., the SQL-3 Committee; namely, the development of a database language for an object-oriented database as a post-relational database. The primary goal of the ODMG, as stated on page 2 of the book, "... is to put forward a set of standards allowing an ODBMS customer to write portable applications, i.e., applications that could run on more than one ODBMS product." This differs considerably from what Dr. Kim describes as the goal of ANSI X3H2, with respect to SQL3, as "... an Object SQL which extends SQL-2 with facilities for defining,manipulating, and querying an object database as a superset of a relational database." The SQL-3 committee includes all major relational database vendors, and some OODB vendors. This is incorrect. At the time Dr. Kim prepared his commentary, none of the ODMG member companies were members of ANSI X3H2 (the committee referred to). The ODMG has established a liaison with X3H2 but has not been active, yet amore active role is being considered by the ODMG Board. The phrase, "...some OODB vendors," must refer to Dr. Kim's company, UniSQL. Although members of ODMG are supposedly to implement the ODMG-93 proposal within 18 months, at this point it is not clear how many of the members willactually do so, and how much of the proposal they will implement. Although Dr. Kim is certainly entitled to his opinion, there is no basis for this statement. Part of the reason for issuing Release 1.1 of ODMG-93 is to incorporate the feedback received from the vendors as they began to implement the specification. Also, to be a Voting Member of the ODMG, the company must formally commit to implementing the specification. The seven ODMG Voting Members are Object Design, Objectivity, ONTOS, O2 Technology,POET Software, Servio Corporation, and Versant Object Technology. Additionally, the ODBMS vendors who happen to be Reviewer Members have informally committed to implementing the ODMG-93 specification within the same time constraints as the Voting Members. The technical challenge of implementing the full ODMG language, especially the automatic query optimizer and query processor, is one that is unlikely to be met in 18 months. Again, this is strictly an opinion of Dr. Kim's. But since he singles out the query capability, it should be noted out that the ODMG OQL is based on the O2 Technology query language which is a commercial product that currently has an automatic query optimizer and query processor. ODMG had five original members: Object design, Inc., O2 Technology, Versant ObjectTechnology, Objectivity, Inc., and ONTOS. The companies listed above were the companies employing five primary authors of ODMG-93. At the time ODMG-93 was first published, the total membership had grown to 12 companies. They are clearly listed on page 7 of the book. However, VersantObject Technology has opted for a joint development and marketing of an Object SQL product based on UniSQL's SQL/X object-oriented SQL. This is the start of a series of misleading statements by Dr. Kim concerning the ODBMS vendors' interest in having a SQL-compliant interface. It is predicated on his argument that if you support SQL, you are not likely to support the ODMG-93 Object Query Language (OQL). A number of vendors want to include SQL as an interface to their products. SQL2, however, cannot take advantage of the object model. The SQL3 specification is still in the formative stages and is not yet really even aspecification. SQL3 is expected to be available as a specification in 1997. OQL is the choice of the ODMG ODBMS vendors when it comes to object queries because the specification can be implemented now. Objectivity, Inc. has announced a plan to deliver an object-oriented SQL product by early 1994 which extends a pure SQL language processor they licensed from an SQL vendor (Objectivity claims that they will offer both the SQL interface product and an ODMG-based query language product.) The use of the term "claims" in the parenthetical phrase minimizes what would be better described as the "plans" that Objectivity has publicly announced. ONTOS has had their own (limited) Object SQL for some time. Dr. Kim is further elaborating his SQL argument. HP also has an OSQL. Other ODBMSs have other query capabilities. That is fine and good, but in no way does it preclude supporting OQL in addition to SQL. O2 Technology claims that it already supports ODMG-93. The actual claim is that O2 Technology supports the ODMG OQL. In fact, ODMG adopted OQL from O2 Technology's product. It seemed to make sense to use a functioning product rather that starting from scratch. Although it is not a member of ODMG, UniSQL also supports most of the features found in ODMG- 93, albeit in somewhat different syntax. Claiming to support the feature but not the syntax really does not mean much. Much what ODMG-93 is trying to do is the standardization the syntax for a given interface. Following Dr. Kim's reasoning, it would be similarly fair to say most of the features of ODMG-93 are currently supported by most of the ODBMS vendors and always have been. The differing syntax was part of the major task for the ODMG goal of portability. Standardizing on syntax is one of the achievements of ODMG-93. This is a "non-statement" on the part of UniSQL. The biggest problem with the ODMG-93 database language is that it fails to recognize that the OMG Core Object Model on which it is based to is a superset of the relational model of data, and as such the ODMG database language should be a superset of ANSI SQL. The ODMG object model is based on the OMG model. It does not, however, follow that this means the database language should be a superset of ANSI SQL. This is simply furthering Dr. Kim's misleading SQL argument from earlier in his commentary. ODMG plans on supporting many interfaces. Someday, SQL3, when it is available, may very likely be one of them. Currently, C++ and Smalltalk are supported in ODMG-93. It also has no SQL-like statements for creating new objects, updating a set of objects based on query search conditions, etc. There is indeed support for creating and updating objects and sets; this is done via methods embedded in the OQL and via the bindings to object languages, C++ or Smalltalk, which can be intermixed with the declarative queries of OQL or with other object constructs of these languages. As opposed to an SQL-like UPDATE, method calls do not violate encapsulation. The ODMG-93 database language has various little facilities that will add up to a"meta-data management" nightmare. For example, it proposes to allow a user to specify multiple names for a single object; to specify the lifetime of a single object, to create an index on a subset of an extent of a type (i.e., a subset of all instances of a type * equivalent to a subset of all records of a table in a relational database); to create multiple such subsets of an extent of a type, such that some objects may belong to more than one subset; to name a query statement and use it in other queries, etc. We believe in the wisdom of the programming language world and of the OMG on naming. It is better than that of traditional DBMSs. It should be possible to name anything, not just types. OMG argues that a "meta-data management nightmare" may in fact come from traditional DBMS assumptions in a heterogeneous distributed environment, e.g. for type extents. The solution to the problem is along the lines of mechanism like the OMG distributed name services which define specific name contexts. (These have been agreed on after ODMG-93 was released, but ODMG will probably define something along these lines.) The ability to name individual objects and to have multiple overlapping subsets of all objects of a type is designed to avoid a "meta-data management nightmare," not to create one. There is a fundamental misunderstanding of OMG's object model on the part of Dr. Kim. OMG does not say that type extents will be generally accessible. It will often not be possible to locate all instances of a type in a distributed heterogeneous environment. ODMG follows suit, but adds this as an option. Both the C++ and Smalltalk bindings force all objects to be persistent; and this is regarded as totally unacceptable to some users and prospective users of C++ andSmalltalk. This statement is wrong. These bindings do not force all objects to be persistent. 2. Technical Contributions of Dr. Kim's Commentary Once we get past the misleading statements in the first part of the commentary, Dr. Kim provides some useful input to the ODMG specification. The first two have to do with explaining the ODMG Object Query Language (OQL) better. So you should soon be seeing papers that discuss the following issues Dr. Kim raised in his commentary: * Semantics of queries involving methods * Semantics of queries involving nested data The current ODMG OQLsupports both, they simply need to be explained more fully. Other suggestions from Dr. Kim are currently being put to membership vote for priority ranking along with other suggestions from the ODMG membership and the technical community in general. The results of the vote will be part of the work plan of our next major release, current dubbed "ODMG-95". The suggestions from Dr. Kim that are being considered include: * Allowing hierarchical queries on subtypes * Views * Access authorization * Syntax differences between OQL and SQL where it appears to not be necessary * Dynamic changes to the database schema * Certification of ODMG-93 compliance It should be noted that our membership had also come up with many of the same suggestions. 3. What ODMG-93 Is The first section of Dr. Kim's commentary was entitled "What It Is and What It Is Not" in reference to the ODMG specification. Dr. Kim went on to provide his view of what ODMG-93 is not. To describe what ODMG-93 is, we provide the following summary which is from page 4 of the ODMG-93 book: ObjectModel. The common data model to be supported by ODBMSs is described in Chapter 2. We have used the OMG Object Model as the basis for our model. The OMG core model was designed to be a common denominator for object request brokers, object database systems, object programming languages, and other applications. In keeping with the OMG Architecture, we have designed an ODBMS profile for their model, adding components (e.g., relationships) to the OMG core object model to support our needs. Object Definition Language. The data definition language for ODBMSs is described in Chapter 3. We call this the object definition language, or ODL, to distinguish it from traditional database data definition languages, or DDLs. We use the OMG interface definition language (IDL) as the basis for ODL syntax. Object Query Language. We define a declarative (nonprocedural) language for querying and updating database objects. This object query language, or OQL, is described in Chapter 4. We have used the relational standard SQL as the basis for OQL, where possible,though OQL must support more powerful capabilities. We have not used the extended relational standard in progress, SQL3, because of limitations in its data model and because of its historical "baggage." However, we hope that OQL and SQL3 can converge at a future date. C++ Language Binding. The most important programming language for ODBMSs has proven to be C++. Chapter 5 discusses the standard binding of ODBMSs to C++; it explains how to write portable C++ code that manipulates persistent objects. This is called the C++ OML, or object manipulation language. The C++ binding also includes a version of the ODL that uses C++ syntax, a mechanism to invoke OQL, and procedures for operations on databases and transactions. Smalltalk Language Binding. We have also drafted an ODBMS binding for Smalltalk, to support applications for which that is the most appropriate programming language. It is possible to read and write the same database from both Smalltalk and C++, as long as the programmer stays within the common subset of supported data types. In order that the importance of the language bindings be understood, we will repeat the earlier statement that unlike relational DBMSs, ODBMS data manipulation languages are tailored to specific application programming languages, in order to provide a single, integrated environment for programming and data manipulation. We go further than relational systems, as we support a unified object model for sharing data across programming languages, as well as a common query language. Future Course for the ODMG The ODMG membership is growing as user companies are joining in to assist in the next major release of the ODMG specification. As of June 15, 1994, the Voting Members are Object Design, Objectivity, ONTOS, O2 Technology, POET Software, Servio Corporation, and Versant Object Technology. The ODMG Reviewer Member companies are ADB/Intellitic, Andersen Consulting, EDS, Hewlett-Packard, Itasca Systems, MICRAM Object Technology GmbH, Persistence Software, Sybase and Texas Instruments. Since the publication of Release 1.0, a number of activities have occurred. * Incorporation of the ODMG and the establishment of an office. * Affiliation with the Object Management Group (OMG) and in February 1994, OMG adopted a Persistence Service that endorses ODMG-93 as a standard interface for storing persistent object state. * Establishment of liaisons with ANSI X3H2(SQL), X3J16 (C++), and X3J20 (Smalltalk). * Re-definition of Reviewer membership to allow the user community to participate more fully in the efforts of the ODMG. * Publication of several articles written by ODMG participants that explain the goals of the ODMG and how they will affect the industry. * Collection of feedback on Release 1.0, of which much was used in Release 1.1. We now plan to proceed with several actions in parallel in order to keep things moving quickly. * Distribute Release 1.1 through the ODMG-93 book. * Continue implementation of the specifications in our respective products. * Collect feedback and corrections for the next release of our standardsspecification. * Continue to maintain and develop our work. * Submit our work to OMG or ANSI groups, as appropriate. 5. Summary In this paper, we have set the record straight as to the goals the Object Database Management Groupand what the ODMG-93 specification represents. We, as a consortium of vendors, are trying to make the choice of using an ODBMS easier for users through the portability that will be achieved byconformance to the ODMG-93 specification. We invite technical commentary on our work. We also welcome new members who are willing to work with us in further developing the ODMGspecifications.