RE: more detailed version of query schema for simplesearch

At 02:08 PM 6/26/98 PDT, Babich, Alan wrote:
>>(1) Jim Davis: "How would you state capabilities of "all" 
>>properties without listing them all?"
>
>I wouldn't. I would just list all the properties along with their
capabilities/attributes. 

Ah, but this means the server has to have a list of every properties on any
resource in the scope, and that could be expensive to obtain and large to
transmit.  Better to use "allprops", I think.

Didn't we agree that some servers might be unable to obtain this list?  The
allprops tag covers this case as well.

>>(2) "Yes, I took the operator list out on the theory that ...".
>
>We are chartered to spec. a way to advertise the query capaibilities of
collections. To me, this consists primarily of advertising the properties
(and their capabilities/attributes) and the query operators that are
supported (and the limitations on the forms of their operands) .

I fully agree that we must provide means of advertising properties, and
leave it to the list to decide whether there are any optional operators.
If so, then I will extend the syntax to allow them.  It's not hard.

>...our deepest disagreement is on whether simplesearch
> should be ... extensible ... or a limited, never-to-be-extended grammar.

Yes, that is precisely the issue, and it would be well for the list to
consider it carefully.  This is a fundamental issue, and should be settled
first.  I would add that while my current position is that simplesearch
need not be extensible it is not a firmly held position.  Speak up, you
lurkers.

> At the Redmond meeting, it is my recollection that when asked during my
> presentation, possibly excepting you, the people attending were either
silent or 
> agreed with having extensibility, assuming we didn't have to give up
anything. 
> That is, all else being equal, an extensible framework would clearly be
better.

Regrettably, the minutes are not yet on line, so it is difficult to tell
whether the Redmond group reached concensus on this point.  But of course,
all things being equal, extensibility is a good thing.  The issue is how
much we need it and what price we will pay for it.

Perhaps though it would be better for us to concentrate on bringing the
remainder of the design to completeness, in particular the content
operators.  Then we'll be able to tell to what extent we need to support
optionality and/or extensibility in the query language.  If for example we
find the need to define 16 variations of content operators (e.g. like,
phrase, para, near, soundex, etc.) this would make it more likely that we'd
need to support optionality and/or extensibility.  So why not take up this
issue now?

best regards

Jim

Received on Monday, 29 June 1998 20:45:28 UTC