Re: Suggestions for DQL changes made at Portland

From: Richard Fikes ([email protected])
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?

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