From: Neil Goldman (ngoldman@teknowledge.com)
Date: 04/14/03
I believe these are all straightforward. Except maybe for the last one. :) ============== 1. The choice of the term process handle is unfortunate. There is nothing about processes in this specification, and nothing that even suggests there would need to be a direct relationship between one of these handles and a process, as the term is used in operating systems. Certainly someone might implement a server,or a client, where such a correspondence existed -- but then, I could implement one where a correspondence to a FILE existed and that wouldn't justifiy calling them file handles. The description of a process handle in the document is just fine -- why not simply call it a query handle and avoid the unhelpful tie-in. ======================== 2. The specification should provide a 3rd reserved termination token, QueryError, as the suggested (or better yet, required) response from a server when a client fails to meet its obligations in the protocol. There are numerous requirements placed on the client, e.g. * The must/may/dont lists must be disjoint * Each variable must be used in the query pattern (or answer kb pattern) * bundle size, if specified, is a positive integer * process handle in a server continuation must be the one most recently produced by the server It's certain that any server implementation is going to have to detect client failures to satisfy some, if not all, of the client's obligations. We might as well provide a well-defined response from the server to deal with it. (most client-server protocols has some sort of "error" response from the server) As an implementer of a client, I would be unhappy if end were ambiguous as to whether the server was unable to answer or my request was malformed. ======================== 3. In the description of the variable lists, the document says "every query variable must be an element of exactly one of these lists". Since membership in one of these lists is what defines query-variablehood, I'd suggest rephrasing this as "these lists must be pairwise disjoint" ============================= 4. The description of a query answer states that "Each element of the binding set is a lexical mapping that associates..." I can't imagine what the qualifier lexical is adding here. Perhaps a proposal for an external syntax for this protocol might choose a representation that could justifiably be described as lexical, but I don't see what it adds in this proposal. ========================== 5. Although this specification does not commit to an external syntax, is it the intent that any syntax chosen will be such that it is impossible for a VARIABLE (one of the things in the may/must/dont bind lists) to coincide with a uri or value that could actually appear in a premise or a KB? ========================= 6. The spec says that an answer includes the query to which it is an answer. (as one of 3 required parts) Minor nitpick -- Won't all the answers in the answer collection of an answer bundle contain the SAME query? If so, then why not promote it to the anwer bundle, rather than make it part of each answer? The same applies to the server reference component of an answer, if it is common to all answers in an answer collection. That promotion in fact is what was done in the example published in http://ksl.stanford.edu/projects/dql/syntax.shtml <http://ksl.stanford.edu/projects/dql/syntax.shtml> although it is not clear whether that example is really meant to comply with this spec --e.g., it omits the required server reference component of the answer, and it repeats only the query pattern, not the entire query, in the bundle. Major nitpick -- why should the server be sending the entire query, or even the pattern, back to the client? This is not motivated in the spec -- the only thing I can think of is that it allows us to deal with cases where a client is interleaving multiple conversations with the same server, and so needs to know which query a given bundle pertains to. But that can be handled by simply allowing the client to provide an opaque name --an uninerpreted string-- as a component of the query, and requiring the server to repeat that name as a component of each response. Maybe I'm completely off-base on the motivation? Because the server doesn't always send back an answer bundle. Sometimes it sends back a termination token instead. Since a termination token does not include a query and a server reference the way an answer does, there would be no way for the client to determine which of multiple outstanding queries was being terminated. Must be something else going on here... p.s. The document at http://www.daml.org/2003/04/dql/dql <http://www.daml.org/2003/04/dql/dql> has had its content, but not its HTML title, updated: <HEAD><TITLE>DQL (August 2002)Abstract Specification</TITLE> Neil Goldman Tel: (310)578-5350 x204 Teknowledge Corporation Fax: (310)578-5710 Suite 231 4640 Admiralty Way Marina del Rey, CA 90292
This archive was generated by hypermail 2.1.4 : 04/14/03 EST