RE: proposed additions for discovery, sorting, and typed values

Thanks for your thoughtful reply

At 11:18 AM 3/16/98 PST, Saveen Reddy (Exchange) wrote:

> Suppose a server
>offers searching on every resource ...
> Would the queryschema property have to be defined
>on each on of those resources? That seems like it be potentially a lot of
>data stored on each resource just to support the search method.

Judy Slein has already shown that the arbiter is the wrong place to store
the schema, as it more properly belongs on the scope.  Having conceeded
that, it's still worth addressing your scenario.

The query schema would be DEFINED on every resource but it need not be
STORED (separately) for each.  It can be computed on demand.  In fact I
can't imagine a queryschema NOT being a live property, since it makes no
sense to have a server that does not understand the syntax and semantics of
the query schema.

>...Use the DASL: part of the OPTIONS response; it could
>point the client to a resource that has the relevant queryschema property.

This is cool, but suggest back a modification of it.

Seems to me to search a URI (assuming one knows it exists already and wants
to search it), there are three logical steps
 1) Find an arbiter.
 2) Find query syntax(es) supported by that arbiter.  
 3) Find query schema supported by arbiter for that syntax.

In your scenario, step 1 is trivial, every URI is also an arbiter.  It
could als be done by a property (as in the email I sent a few minutes ago)
or by adding this to the DASL header.

Step 2 is defined by the DASL header in the current proposal.

For step 3 I had earlier proposed to use a property of the arbiter URI, but
Judy has explained why that's a bad idea.  You're proposing to extend the
DASL header to contain this information, but I think that's a mistake for
same reason as Judy explained.  It's fine if one is searching exactly one
resource, but problematic if searching a set.

Received on Monday, 16 March 1998 15:56:10 UTC