W3C home > Mailing lists > Public > www-webdav-dasl@w3.org > April to June 1998

RE: more detailed version of query schema for simplesearch

From: Babich, Alan <ABabich@filenet.com>
Date: Mon, 29 Jun 1998 18:06:11 -0700
Message-ID: <72B1992276A9D111A20E00805FEAC96DCC4112@cm-expo1.filenet.com>
To: "'Jim Davis'" <jdavis@parc.xerox.com>, www-webdav-dasl@w3.org
OBSERVATION: Document Management Systems won't have any
problem whatsoever enumerating their metadata in an degree
of excruciating detail that you could ever possibly wish for.
They are one interesting case. Then there's the file system case,
where the files can have properties. For that case, yes, it
would be a problem to enumerate the properties. What I
believe our thinking is on this issue is, is to allow the collection
to advertise the facts that (a) it supports the properties required
by WebDAV (of course), and (b) it is not prepared to advertise
the rest of its properties.

Now, the problem with not advertising all the properties of a
collection vis a vis the "allprops" concept is that it only takes
one property to blow the applicability of "allprops" out of the water. 
For example, if a collection doesn't allow the "getcontentlength" 
property to be in the where condition, only in the selection list, then
"allprops" no longer applies to the searchability aspect
of all the properties of the collection.

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:08:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:22:39 UTC