From: [email-masked]
Date: Fri, 16 JUL 93 16:06 GMT

RFC-822-Headers:
Received: by isosun.ariadne-t.gr (4.1/SMI-4.0-MHS-6.0)
	id AA08608; Fri, 16 Jul 93 16:34:19 +0300

FROM: Nikos LorentzosTO  : Everybody interested in contributing
to group SQL2/3.
 
Subject: Establishment of SQL2/3 Working Group
 
Dear Colleagues,
I would appreciate having your comments
on the message which follows and I would
also like to know whether you are interested in
participating in the SQL2/3 group.
Regards,
Nikos
----------------------------------
MESSAGE BEGINS
 
Dear Colleagues,
Following the workshop which took place at Texas,
three distinct working groups were established for the definition
of an extension to SQL for the management of temporal data.
There follow next two e-mails.
The first one is a redirection of an e-mail
by Rick Snodgrass where the objectives of each group are specified.
The second one is a mail from me, concerning
the initiation of group SQL2/3, for which I am the coordinator.
 
I would appreciate being informed whether you are interested
in participating in this group.
 
Please note that my e-mail address is
[email-masked]
 
Best Regards,
Nikos
 
-------------------
Rick's e-mail:
 
qqq
--------------------------
My e-mail:
 
FROM: Nikos Lorentzos
TO  : Everybody interested in contributing to group SQL2/3.
 
"Proposal to Initiate the SQL2/3 Group - Time schedule"
 
Dear Colleagues,
 
I would firstly like to thank all of you
who participated at the workshop at Texas.
We really had the opportunity to exchange ideas
and come closer to each other's view.
 
As a coordinator of SQL2/3 group,
it is my pleasure to invite all of you, and also
all others who have access to [email-masked],to freely express your ideas within the limitations
of SQL2/3 group, as described by Rick.
In particular, our objective
is to incorporate in SQL an interval data type
and reach a widely accepted agreement on the design
of a temporal extension to SQL.
Clearly, this is not easy, since each of us
may be influenced by one's own different approach
both in the definition of a relational algebra
and also in the definition of an SQL.
At the same time, until August 23,
we have almost 1.5 month ahead.
(For details about the time schedule, please
read the end of the e-mail.)
As a consequence, we would be excessively ambitious
if we promised that we would reach a complete agreement
on the design of TSQL.
I believe however that we can really succeed,
if we start from some simple issues.
My opinion is the following:

SQL 2/3 Group Initiation
_________________________
1. As a first step, completely ignore transaction time,
it is important to simplify the problem.
 
2. SQL should functionally and semantically
be a consistent extension of SQL.
This implies that the result of our effort should not,
in any way, violate the rules which standard SQL obeys.
If for any reason we violate this principle, it is definite that
the database community will reject our effort,
since people have been using SQL for many years.
 
3. Maintain simplicity.
The more complicated a tool is,
the less user friendly it is.
However, TSQL should address a wide community
and not just a few experts.
 
Having the above in mind, I think that we can reach a goodagreementon
the design of TSQL,
if we start identifying certain primitive properties
which TSQL should have.
To make this point clear, I find it necessary to point out that the
characteristics of any data model
can be classified into the following categories:
 
1. Valid data types.
2. Valid data structures (valid relations).
3. Relational algebra operations.
4. Functions and Constraints which should be supported.
5. Semantics which should be captured.
 
I think therefore that we should try toanswer questions on the above issues.
Some simple example questions which we should answer with
respect to the above are the following:
 
1a) Should we support time-points, time-intervals, both types?
1b) Should a time interval an individual data type or
should it be expressed in terms of two attributes?
1c) Should we consider discrete or continuous time?
2a) Should a snapshot relation be also valid valid time relation?
3a) Should the operations of he snapshot relational model
remain the same in the valid time model
or should they be extended? If yes, which ones and how should they
be extended?
 
In the paper which I submitted to the Texas workshop, I had tried
to answer such queries, hoping that I would contribute
in a consensus.
It is obvious that it represents personal ideas only.
To initiate therefore our collaboration,
I think that the above questions could be a good starting point.
 
Time Schedule
_____________
If you all agree, I suggest that
we can devote the first 4-5 days
in a collection of such properties.
This will help make an estimation of how much work
we have to do.
We shall next start identifying one by one the properties in which
we all agree.
For properties in which we have different views,
it will be necessary to provide reasonable justifications.
 
Please note that I do not find it necessary
to express my personal ideas.
They are in the paper I submitted to the workshop
with some justification,
to the degree I could justify my view
in a limited number of pages.
 
Please note that in order that a first report
is ready on August 23,our work must actually be finished by
August10.This will allow collect and classify our conclusions
in a a draft report, next we all shall have the opportunity
to look at it thoroughly and make our final amendments,
so as to finalise and submit it on the deadline.

FINAL COMMENT
_____________
To enable easy references to the properties
identified by others,
I suggest that each of us enumerates
the properties he proposes, prefixed by his surname.
For example in John
identifies 3 properties,he can enumerate them as
JOHN1, JOHN2, JOHN3, so as
to avoid long descriptions when
we want to refer to one of them.
Mine are number in the workshop paper.
 
I shall be expecting your comments.
Regards,
Nikos