Scope

• TSQL is to be a relational query language.

  Given that SQL is ``intergalactic dataspeak'' (Mike Stonebraker's term), TSQL should whenever possible be consistent with standard SQL, specifically, SQL89. It simply doesn't make sense to base TSQL on competing (and arguably better) query languages such as Quel, Datalog, or Daplex. (Given that my language design work is based on Quel, I find it particularly painful that SQL has dominated over that superior language.) While I strongly agree that interesting research is possible and even desirable in extending the other languages to include temporal support, such extensions are necessarily outside of the scope of TSQL.

• TSQL need not be consistent with existing standards.

  In general, TSQL need not be consistent with SQL2, which is in the final standardization process, nor SQL3, which is currently being designed. SQL2 contains severe flaws in its (minimal) handling of time-stamps, and SQL3 is a moving target which, in its present state, is regarded by many as a baroque design with a bewildering array of features. Consistency with the non-temporal aspects of existing standards for SQL, including SQL89, SQL2, and SQL3, is desirable if such consistency does not conflict with other goals.

• TSQL will not be another standard.

  While the goal is a fully elaborated language design, there is no expectation that this design will be made into a standard. Of course, one hopes that our results would be acceptable to the standards bodies; at a minimum, our design should be communicated to these bodies. However, it is important to keep in focus the objective of the TSQL design: to provide a basis for future research in temporal databases. It also must be emphasized that TSQL should in no way limit or constrain future research in temporal databases, which should be free to adopt or propose whatever linguistic constructs are appropriate.

• TSQL will not be an object-oriented query language.

  While temporal object-oriented query languages are being actively investigated, it would be distracting and counter-productive at this stage to attempt to merge the rather disparate approaches of object-oriented and relational languages while also addressing the temporal processing needs. Those involved in object-oriented language design are encouraged to produce, in parallel with this effort, a temporal object-oriented extension to SQL. At a later date, the two extensions could be merged.

• TSQL should be comprehensive.

  TSQL should have constructs, extended in a natural fashion, that support all of the functionality of SQL, including update, aggregates, and schema specification and evolution. Consistent with the modifier ``temporal'', TSQL should support both valid and transaction time.

• The language design should include a formal semantics.

  Fortunately, there is a tradition of rigor in the temporal database community. The recent publication in TODS of a straightforward semantics of SQL will also help here.

• The language will have an associated algebra.

  Such an algebra would demonstrate the existence of an executable equivalent to the declarative constructs in the language, and would suggest implementation strategies.

• TSQL will be a language design.

  The TSQL design should not attempt to define storage structures, indexing structures, access methods, fourth-generation interfaces, support for distributed systems or heterogeneous databases, or optimization techniques. Such aspects, while important, are more properly the target of the research efforts that will utilize TSQL as a common substrate.

• TSQL should reflect areas of convergence.

  The design of TSQL should avoid active areas of research where new results are generated frequently. Such areas include historical indeterminacy and temporal database design.