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: Lisa Dusseault <lisa@xythos.com>
Date: Fri, 25 Jan 2002 17:25:36 -0800
To: "Babich, Alan" <ABabich@filenet.com>, <www-webdav-dasl@w3.org>
Message-ID: <HPELJFCBPHIPBEJDHKGKKEOHDEAA.lisa@xythos.com>
I already understood how a server might specify like, eq or no searching
support for a given, specified property.  I still don't see how DASL QSD
would show whether a server supports like, eq or no search support for
*unspecified* properties.

You say the server could advertise each custom property, I say that's
infeasible.

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 5:10 PM
> To: www-webdav-dasl@w3.org
> Subject: RE: Call for Participation: new internet draft for WebDAV
> SEARCH method
>
>
> 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:27:13 GMT

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