- From: Jim Davis <jrd3@alum.mit.edu>
- Date: Wed, 17 Nov 1999 22:02:02 +0100
- To: "WWW WebDAV DASL (E-mail)" <www-webdav-dasl@w3.org>
At 06:26 PM 11/1/99 +0000, Mark Birbeck wrote: >...The server has some object which is at a known location which contains >WebDAV info - is it locked? when was it created?, etc. - as well as info >from another namespace. So under normal WebDAV operation I am able to >access all properties of an object. Now, if I want to find all objects >that are currently locked out to a particular user, or all objects >created after a certain date, I am assuming I have to move to DASL. Yes. The prime motivation for DASL is to make it easier to locate WebDAV resources. A client could in theory locate all resources matching certain conditions (e.g. created after a certain date) by issuing a PROPFIND with depth infinity, and then examining the results client side. But this would be very inefficient, as the DASL charter observes, and hence we have DASL. So, to follow your use case >So how do I delete all items created before October 1st, or unlock >everything that is locked out to a particular user? You issue the DASL request, get back a list of URLs, and then call DELETE. (Well, set aside for a moment the fact that there is no way in DASL basicsearch to express a query that finds resources locked by a particular user -- to do that, you need a way of querying the XML body of the lockdiscovery property, which basicsearch lacks. We hope to use the XML query language that the W3C is working on for that, in a future DASL query grammar. But that's a side issue.) So this represents use of DASL in an situation where the DASL search arbiter operates on the same server as the WebDAV server, and cooperates closely with it. I expect this to be the predominant use of DASL. But the "restaurant finder" example shows a different application of DASL. here, the search arbiter is storing information about some totally other set of resources, without necessarily the knowledge or cooperation of the server where those resources are located. So yes indeed, in this case, as you say, when you send the query to DASL, you get a set of response elements with hrefs not necessarily on the same server as the arbiter. You shouldn't expect to be able to manipulate either the index data the server operates on, or the resources that you get back, any more than you can change the index data that say Google uses, nor to be able to delete the URLs that it returns for you. This isn't the only way to use DASL, it's just one. So the limitations that apply in this case don't apply to DASL in general. Perhaps the restaurant finder example in the dasl protocol draft is just too confusing? >My feeling so far is that this approach caters for one use of DASL, >which is to hold indexes to other resources. But by gearing everything >to that, don't we lose the ability to search the index entries >themselves? Perhaps the draft document is faulty in giving the impression that "everything" is geared to this means of use? You can use DASL in many ways, this is just one. Have I given you the impression that everything works in the way the restaurant finder does? >To pose it a different way; why should the format of the result of a >PROPFIND on a known URI be different to a DASL query on some container >that includes that same URI? In other words, there is no notion of "what >are the properties of this object", since the answer is "depends on how >you ask the question". Well yes, but in fact even on a plain old WebDAV server, the answer could depend on your authentication -- I might get a different answer than you get. Does this help? Jim
Received on Wednesday, 17 November 1999 16:04:22 UTC