Re: Suggestions for DQL changes made at Portland

From: Richard Fikes (fikes@ksl.stanford.edu)
Date: 10/27/02

  • Next message: Benjamin Grosof: "current version of Description Logic Programs paper and talk slides" 
    > This message is an attempt to summarize the suggestions made at the 
> PI meeting concerning changes to the DQL spec.

> I recommend that we make these changes to 
> the spec, and the obvious ancillary simplifications that they produce.

I agree, with the following additional comments --

> 1. Non-fixed bundle size
> 
> A client can return a revised bundle size bound with each 
> continuation. If this is omitted, the previous bundle size bound is 
> assumed.

This suggestion prompts me to recommend that we make a minor refinement
in our terminology in the client-server protocol specification. 
Specifically, we say in the spec that (1) a "server continuation" is
included in an "answer bundle" that is passed from the server to a
client, (2) a "server continuation" is either a "process handle" or "one
or more termination tokens", and (3) that a client passes a "server
continuation" back to the server as a way of requesting more answers
from the server.  We now want to add a "bundle size bound" to what a
client sends to the server when requesting more answers.  Also, in
general, we want to allow servers to support various extensions to the
core protocol described in the spec, and so I think we want our spec to
be structured so that additional property-value pairs can be included in
the messages that are passed between clients and servers, as supported
by the particular server.

Our current design is "overloading" the notion of "server continuation"
in that the server includes a server continuation in what it sends the
client, and then a client sends the server continuation back to the
server (in order to request additional answers).  But we want the client
to be able to send the server more than the process handle that is the
server continuation, e.g., at least a new "bundle size bound".

I recommend the following change in terminology.  We change the spec to
say that an answer bundle consists of an answer set and either a process
handle or a set of termination tokens (i.e., we don't call what's in an
answer bundle a server continuation).  We then say that a client sends a
server continuation to a server as a way of requesting more answers and
that a server continuation necessarily contains a process handle and
optionally contains a bundle size bound.  Servers can then specify
additional optional property-values for server continuations, just as
they can do for queries and for answer bundles.

> 2. Number of answers.
> 
> Optionally, a bundle can begin with a number indicating the number of 
> answers still to be delivered *after* the current bundle. The answer 
> number of any bundle containing a terminator should be zero. There is 
> no default value: if the answer number is omitted, then no 
> information is supplied about the number of answers.

Let's simply make the number of answers still to be delivered after the
current bundle a value of some optional property in an answer bundle
(rather than saying "a bundle can begin with ...").

> 4. Answer templates.
> 
> A query must supply an answer template, which is a character string 
> (?? Piece of DAML?? I prefer the more generous definition) containing 
> some of the variables in the query pattern. If no answer template is 
> explicitly provided, then the query pattern is the default answer 
> template (Sandro's idea).

The answer template interacts with the must-bind variables list and the
may-bind variables list.  We need to make some design decisions about
that interaction.  We could say that the variables in the answer
template *are* the may-bind and must-bind variables, and then that a
query can optionally include a must-bind variables list indicating which
of the variables in the answer template must have a binding in an
answer.  There would then be no need for a may-bind variables list. 
That would remove redundancy from the query, but would require more work
by the server.  ...

> 6. Session ending.
> 
> A series of transactions between client(s) and server consisting of a 
> query followed by  answer bundles and continuations is an 'answering 
> session'. If such a session is interrupted or terminated by an 
> underlying network control layer, then it is permissible for a server 
> to be unable to continue the answering session even if it is sent a 
> continuation. In such cases the server should respond with an answer 
> bundle containing the terminator 'end'.

I don't see how this impacts the DQL spec.  That is, do we need to say
anything about this in the spec?

Richard

    This archive was generated by hypermail 2.1.4 : 10/27/02 EST