- From: Surendra Reddy <skreddy@us.oracle.com>
- Date: Tue, 3 Mar 1998 10:07:00 -0800
- To: "Alex Hopmann" <hopmann@holonet.net>, <www-webdav-dasl@w3.org>
- Message-ID: <004f01bd46cf$2989c030$bd0a2382@thunder.us.oracle.com>
Alex, |:The goal of this working group is to provide searching |:interoperability among the variety of underlying storage |:systems whose data can be exposed by the WEBDAV extensions to |:HTTP. The working group will define HTTP extensions that enable |:server-executed queries to locate resources based upon their |:property values and text content. I would recommend the following changes to DASL charter. "The goal of this working group is to define and develop an extensible DAV Searching and Locating protocol as extensions to HTTP.The working group will define HTTP extensions that enable server-executed queries to locate resources based upon their property values and text content as exposed by DAV as well as other interoperable HTTP applications." With this change incorporated, I am full agreement with DASL charter. Appreciate your comments. Best regards, Surendra -----Original Message----- From: Alex Hopmann <hopmann@holonet.net> To: www-webdav-dasl@w3.org <www-webdav-dasl@w3.org> Date: Monday, March 02, 1998 5:29 PM Subject: Re: Why DASL need not be DAV-specific >Sounds ok to me. So the question is, does this result in any changes to the >charter? Your two statements below look like stuff for the requirements >document to me. > >Also, those two queries look identical. Please keep in mind that DAV has a >totally open ended property framework, so <d:dma-guid> is a property just >like any other. > >Alex Hopmann >Microsoft Corporation > >Jim Davis wrote: >>At 01:56 PM 3/2/98 PST, Yaron Goland wrote: >> >>> The reason why this working group was formed was to solve search for DAV. >>> ... to provide search facilities which make optimal use of the DAV object >>> model, repository model, variant model, access control model, and >versioning >>> model...Universal Search is a laudable goal but one that will require >>> compromises we are not willing to make. >> >>Perhaps we could all agree as follows: >> >>1) DASL MUST fully support WebDAV repositories efficiently. >>2) DASL MAY also support other HTTP applications, if such support imposes >>only minor costs (e.g. in added complexity.) >> >>To elaborate on the second point, at present, it seems to me the only DAV >>feature that DASL requires is a property store. Given that we're using XML >>to express queries, it would be very easy to generalize the notion of >>'property' to support property stores other than that of DAV. Surely this >>is not objectionable? >> >>We're talking about the difference between (to use an utterly fabricated >>query syntax) >> >><D:contains> >> <D:prop> <X:author/></D:prop> >> <D:value>Knuth</D:value> >> >>and >> >><D:contains> >> <D:prop><d:dma-guid>123762-72738</d:dma-guid></D:prop> >> <D:value>Knuth</D:value> >> >>Something like that. >> >>As I noted in earlier email, it will also require means to specify query >>scope, which may be a bit trickier to generalize, but not too hard. >> >>It may well turn out that when we get into details, there will be something >>about DAV that will be too hard to generalize, or something about e.g. LDAP >>or Z39.50 that would impose a great penalty on DAV. If either of these >>happen, we should discard the attempt to be universal. >> >>Is this an acceptable framing of the charter? >> >>In the meantime, we can scarcely design DASL's interactions with the >>variant, access control, or versioning models of DAV, before these are >>designed. I at least haven't seen any sign of progress on any of these >>fronts. Can you provide any guidance? >> >>Jim >> >> >>------------------------------------ >>http://www.parc.xerox.com/jdavis/ >>650-812-4301 >> > > > >
Received on Tuesday, 3 March 1998 13:14:39 UTC