Using property expansion and sets in criteria

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Using property expansion and sets in criteria

Werner Donné

Hi,

Consider a question to a server like: "Which VCRs have the
activity x in the activity-set of their checked-in version?"
Two things would be necessary for this. First, where the
"prop" element is expected, a nested prop element should be
allowed as well; something reminiscent of the expand property
report. Second, there should an "in" operator for all those
properties which are in fact sets.

Here is a possible example of the above question:

<d:searchrequest xmlns:d="DAV:">
  <d:basicsearch>
    <d:select>
      <d:prop><d:displayname/></d:prop>
    </d:select>
    <d:from>
      <d:scope>
        <d:href>http://hostname/container1/</d:href>
        <d:depth>infinity</d:depth>
      </d:scope>
    </d:from>
    <d:where>
      <d:in>
        <d:property name="checked-in">
          <d:property name="activity-set"/>
        </d:property>
        <d:literal>http://hostname/act/my_activity</d:literal>
      </d:in>
    </d:where>
  </d:basicsearch>
</d:searchrequest>

Regards,

Werner.
--
Werner Donné  --  Re
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803 e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Using property expansion and sets in criteria

Julian Reschke

Werner Donné schrieb:

>
> Hi,
>
> Consider a question to a server like: "Which VCRs have the
> activity x in the activity-set of their checked-in version?"
> Two things would be necessary for this. First, where the
> "prop" element is expected, a nested prop element should be
> allowed as well; something reminiscent of the expand property
> report. Second, there should an "in" operator for all those
> properties which are in fact sets.
>
> Here is a possible example of the above question:
>
> <d:searchrequest xmlns:d="DAV:">
>  <d:basicsearch>
>    <d:select>
>      <d:prop><d:displayname/></d:prop>
>    </d:select>
>    <d:from>
>      <d:scope>
>        <d:href>http://hostname/container1/</d:href>
>        <d:depth>infinity</d:depth>
>      </d:scope>
>    </d:from>
>    <d:where>
>      <d:in>        <d:property name="checked-in">
>          <d:property name="activity-set"/>
>        </d:property>
>        <d:literal>http://hostname/act/my_activity</d:literal>
>      </d:in>
>    </d:where>
>  </d:basicsearch>
> </d:searchrequest>
>
> Regards,
>
> Werner.

It is a well-known restriction of the basicsearch grammar that it is
simple. This is by design. When it was created, the assumption was that
at a later point it would be replaced by something that is more XML
aware, such as something XPath-based or even XQuery.

That being said, the functionality you're looking for can of course be
implemented as an optional extension to basicsearch (that's why there is
grammar discovery, see
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-09.html#rfc.section.4>).

The right next step would be to write a self-contained proposal, and try
to get at least one additional implementor behind it (otherwise it would
make little sense to standardize it).

Best regards, Julian