Re: QSD: DAV:opdesc

At 04:39 PM 6/25/2002 +0200, Julian Reschke wrote:

>Hi,
>
>currently the description of an operator (DAV:opdesc) includes
>
>- QName of the operator and
>- list of parameter types (DAV:prop, DAV:literal)
>
>I'm not sure about the rational for the latter.
>
>A client will not be able to use an operator unless it knows it's semantics,
>right (*)? If this is the case, it will know it's parameter types as well.

I think there is a difference between having a human user "know" the 
semantics and having a client program "know" it.  The rationale for QSD is 
that it provides enough information for the client (program) to construct a 
valid query.  This is, I think, the minimum that must be done to make it 
possible to have server-defined extensibility.

Suppose a DASL server supports an operator that is an extension to the 
basic search.  To be concrete, suppose there is an operator for spatial 
containment, taking positions in latitude and longitude. There are four 
ways that a client program could support it

1. the client program could be programmed in advance for this specific 
operator.  In this case, the client can be said to "know" the semantics of 
the operator, and even the operands.  (So the client might allow you to 
specify the coordinates by clicking on a map.)  This approach might (and 
probably will)  be used by vendors who control both sides of the protocol, 
because it offers the highest quality of user interface, but it's not flexible.

2. QSD with operators only.  The client could send a query if the human 
user knew the syntax of the operands, and the client was sophisticated 
enough to allow the human to enter such a query, operand by operand.  It's 
a nuisance for the user to use such operators because it takes a lot of work.

3. QSD as it is: the protocol defines the syntax of extension 
operators.  The client is flexible enough to be able to construct an 
arbitrary query that will be syntactically correct, though it does not 
understand the semantics of operators or operands.  The human

4. super-QSD.  The protocol defines the semantics, too.  This would mean 
the semantics of the operator, the operands, and probably the properties also.

The point is, a human has the potential for learning the semantics by an 
out of band means.  It does not matter how the human learns it.  but a 
program has much harder time "learning" anything.  Putting the basic 
knowledge into the protocol adds only a  little complexity (above step 2) 
but enables a much better interface.  Step 4 would be even better, but it 
seems too hard.

Does this help explain the rartionale?

Jim

Received on Sunday, 7 July 2002 16:03:16 UTC