Hi Martin,
Looking at the PROPFIND section I now see that I was confused about the <DAV:prop> element. It seems the way to request multiple properties is to list them inside one single <DAV:prop> element:
<d:prop> <d:displayname/> <Z:authors/> </d:prop>
and this is like you say the way it is implemented in Slide generic basic search implementation.
Sorry for the confusion, thanks for the pointers :-)
-- Unico
Martin Wallmer wrote:
Hi Unico,
You're right, DASL spec says either one <all-prop> or one <prop>
element.
<!-- "select" element --> <!ELEMENT select (allprop | prop) >
But I'm sure, thats not as it is meant. The generic BASICSEARCH in slide
as well as the Tamino specific implementation behaves exactly as you
propose.
The DASL spec also states, that <DAV:allprop> and <DAV:prop> are defined
in RFC 2518 (webdav spec) and should behave like that. In section PROPFIND RFC 2518 says:
A client may submit a propfind XML element in the body of the request method describing what information is being requested. It is possible to request particular property values, all property values, or a list of the names of the resource's properties. A client may choose not to submit a request body. An empty PROPFIND request body MUST be treated as a request for the names and values of all properties.
So I assume, thats a bug in the DASL DTD, funny, that nobody mentioned about up to now. It might be worth discussing on the DASL mailing list.
Regards, Martin Wallmer
-----Original Message-----
From: Unico Hommes [mailto:[EMAIL PROTECTED] Sent: Montag, 5. Juli 2004 12:52
To: Slide Developers Mailing List
Subject: Let DASL select multiple properties
The dasl basic search specification specifies that the select clause can either contain a single <d:prop><property-to-select></d:prop> element or else <d:allprop/> . In order for a basic search request to mimic a propfind this lacks the ability to select multiple properties of choice. What I would like to be able to do is this:
<d:select> <d:prop><d:displayname/></d:prop> <d:prop><H:newsdate/></d:prop> <d:prop><Z:authors/></d:prop> </d:select>
Notice that this does not conflict with the spec but rather expands on it. This would allow one to optimize performance by doing a search instead of a propfind. With the new sql dasl implementation (once it stabilizes), depending on what properties you are requesting and what store topology you have configured, this would mean only 1 (one, uno, un, ein, een) SQL query gets executed instead of Oxn (x being the number of properties, n being the number of resources in the propfind result)
WDYAT?
-- Unico
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
