RE: more detailed version of query schema for simplesearch

OK, I'll start a thread on the operators.

Alan Babich

> -----Original Message-----
> From:	Jim Davis [SMTP:jdavis@parc.xerox.com]
> Sent:	June 29, 1998 5:35 PM
> To:	www-webdav-dasl@w3.org
> Subject:	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 21:10:36 UTC