RE: QSD: DAV:opdesc

Yes,

but isn't there someting *between*

3) (QSD as of now)

and

4) (QSD carries the semantics as well)

that we should consider?

Namely: in addition to operators and parameters, the opdesc element also
carries a human-readable description of the operator?

On the other hand, it's certainly possible that the "new" operator resides
in a namespace for which additional human-readable documention can be
accessed (for instance a namespace document that can be retrieved using GET
from a HTTP based namespace...)

Julian

> -----Original Message-----
> From: www-webdav-dasl-request@w3.org
> [mailto:www-webdav-dasl-request@w3.org]On Behalf Of Jim Davis
> Sent: Sunday, July 07, 2002 10:05 PM
> To: www-webdav-dasl@w3.org
> Subject: 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 Monday, 8 July 2002 09:55:19 UTC