RE: Call for Participation: new internet draft for WebDAV SEARCH method

Julian:

Actually, I think we (you, Jim, Lisa, and I) all on the same page to the
following extent:
(1) The current draft does not require all searchable (or selectable or
sortable) properties to be enumerated in the QS.
(2) The current draft says that if an operator (e.g., "eq") is supported, it
is supported for all properties in the QS specified as "searchable".
(3) The current draft (section 5.20.2.1.1) has a property
"DAV:any_other_property" that allows the QS to state that properties not
explicitly mentioned in the QS are searchable (or selectable or sortable).
(4) For some repositories, supporting QSD is quite reasonable, and for
others it is impractical or unfeasible. Therefore, QSD must be optional.

Alan

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Saturday, January 26, 2002 3:09 AM
To: www-webdav-dasl@w3.org
Subject: RE: Call for Participation: new internet draft for WebDAV
SEARCH method 


> From: www-webdav-dasl-request@w3.org
> [mailto:www-webdav-dasl-request@w3.org]On Behalf Of Lisa Dusseault
> Sent: Saturday, January 26, 2002 2:26 AM
> To: Babich, Alan; www-webdav-dasl@w3.org
> Subject: RE: Call for Participation: new internet draft for WebDAV
> SEARCH method
>
>
> I already understood how a server might specify like, eq or no searching
> support for a given, specified property.  I still don't see how DASL QSD
> would show whether a server supports like, eq or no search support for
> *unspecified* properties.
>
> You say the server could advertise each custom property, I say that's
> infeasible.

I agree with Lisa, because this means that on a non-schema constrained
search scope, a server would first have to visit every single resource to
discover every dead property.

Even if it did that, two resources may have the same dead property with a
different datatype (!).

Besides, a search client can benefit from knowing whether the property list
is exhaustive. If it isn't, it *may* offer a way to specify "arbitrary"
properties, while it could block that otherwise.

This being said: the issue is old and I think the current draft already
covers this. So please don't argue about what a previous draft said about
it -- refer to the current one.

Julian

Received on Sunday, 27 January 2002 18:15:27 UTC