- 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>
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 UTC