RE: HREF Property in Thai Restaurant

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