W3C home > Mailing lists > Public > www-webdav-dasl@w3.org > January to March 2002

RE: Call for Participation: new internet draft for WebDAV SEARCH method

From: Babich, Alan <ABabich@filenet.com>
Date: Fri, 25 Jan 2002 17:09:33 -0800
Message-ID: <C3AF5E329E21D2119C4C00805F6FF58F08FE5A3F@hq-expo2.filenet.com>
To: www-webdav-dasl@w3.org
Lisa:

Thanks for your reply. I think I understand what you meant better now.

If the server supports QSD and custom properties, then it would be a good
idea for the custom properties to be in the QSD, searchable (i.e., allowed
in the "where" condition) or not. (NOTE: The way I read the current draft,
it doesn't seem to *require* *all* of them to be in the QS. Perhaps we
should take a position on the "all-or-none" issue, or maybe I didn't read
the draft carefully enough.) The draft definitely says that a property in
the QS might or might not be searchable (in the sense that it can be in the
query condition), it might or might not be selectable (i.e., returnable),
and you may or may not be able to sort query results on it. The QS specifies
that per property.

However, flatly stating that putting all the custom (i.e., customer defined)
properties in the QSD is infeasible is too strong, and indicates to me what
kind of server you have in mind (viz, not a server running a document
management system). Every document management system my company ever shipped
did exactly that. That imposes a valuable, even necessary, discipline on the
users of a medium or large document management system. However, not every
WebDAV repository is backed by a document management system on the server.
Lacking the discipline of a data dictionary implies that it is very unlikely
that the server will support QSD. 

So the most accurate thing to say is that it may or may not be reasonable
for a server to support a QSD, depending upon whether there's a data
dictionary on the server or not. But that's just a quibble, not what you
were driving at.

The search operators that a server supports are also advertised in the QS.
The intent is that if the server supports an operator, it supports that
operator on all searchable properties in its repository. The draft is for
basic search after all. We have to keep it simple by definition. I think
that is really what you were really driving at. My guess is that you would
like to have a list of operators supported by each property hanging off of
each property in the QS, with a default list of operators supported for any
property. Personally, I don't think basic search would be very basic anymore
if we did that. Not even the sophisticated document management systems of my
company or its competitors do that. 

However, SEARCH may be able to do most of what you want in the current
draft.

"One server might allow substring matches of custom properties ..."

Substring matches are done by the "like" operator. A server that supported
the "like" operator could advertise each custom property, or the
"DAV:any-other-property" wild card property as well as the "like" operator
in the QS.

"another server might only allow exact match searching, ..."

Exact matches are done by the "eq" operator. A server that supported the
"eq" operator could advertise each custom property or the
"DAV:any-other-property" wild card property as well as the "eq" operator in
the QS.

"a third might not allow searching on custom properties at all."

A server that did that could advertise each custom property, and in the
property description for each *not* describe it as being searchable; or it
could advertise the "DAV:any-other-property" wild card property and in the
property description *not* describe it as being searchable.

Am I getting warmer?

Alan

-----Original Message-----
From: Lisa Dusseault [mailto:lisa@xythos.com]
Sent: Friday, January 25, 2002 3:45 PM
To: Babich, Alan; www-webdav-dasl@w3.org
Subject: RE: Call for Participation: new internet draft for WebDAV
SEARCH method 


It could always be me...
As I recall, the DASL spec for QSD says that every searchable property must
be listed in the QSD info.  But what if custom properties are searchable?
There is an unlimited number of possible custom properties, putting them all
in the QSD is infeasible.

But it's not quite right to leave them out of the QSD either.  One server
might allow substring matches of custom properties, another server might
only allow exact match searching, a third might not allow searching on
custom properties at all.  It would be nice if each of these three servers
could advertise how they support searching custom properties.

I didn't see a way in DASL QSD to do this.

Lisa

> -----Original Message-----
> From: www-webdav-dasl-request@w3.org
> [mailto:www-webdav-dasl-request@w3.org]On Behalf Of Babich, Alan
> Sent: Friday, January 25, 2002 3:17 PM
> To: www-webdav-dasl@w3.org
> Subject: RE: Call for Participation: new internet draft for WebDAV
> SEARCH method
>
>
> Lisa:
>
> The search rules are the exactly same whether the properties are
> listed in a
> Query Schema or not. If you don't have a Query Schema, you can search just
> fine if you guess the name of a property to search on, or if you have some
> other way to know the name of a property. There is nothing different about
> the search, whether or not there is QSD.
>
> Perhaps I'm being dense today, but I completely don't get it as
> to how "QSD
> could become a *lot* more manageable ...". Perhaps you would try to
> enlighten me. Thanks.
>
> Alan Babich
>
> -----Original Message-----
> From: Lisa Dusseault [mailto:lisa@xythos.com]
> Sent: Friday, January 25, 2002 3:00 PM
> To: Babich, Alan; 'Julian Reschke'; www-webdav-dasl@w3.org
> Subject: RE: Call for Participation: new internet draft for WebDAV
> SEARCH method
>
>
>
> > That is not the same thing as saying that every repository would be
> > organized enough to provide a query schema. Providing QSD has to be
> > optional. Document management systems could easily provide access to the
> > data dictionary they already have. But other repositories, e.g., file
> > systems, might not have a centralized query schema.
>
> You're right, but it's a little worse than that.  Systems where custom
> metadata could be anywhere (e.g. *any* dav system should support custom
> props) can't provide a complete query schema.
>
> However, QSD could become a *lot* more manageable with the simple
> feature of
> allowing the server to specify their behaviour as follows:  "for any
> property not otherwise mentioned in the QS, searching follows these
> rules..."
>
> Then only the special cases (live properties which are known to
> be integers,
> for example) would have to be in the QSD.
>
> Lisa
>
Received on Friday, 25 January 2002 20:14:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 22 March 2009 03:38:08 GMT