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]

Reply via email to