RE: issue "qsd-optional"

> From: Kevin Wiggen [mailto:kwiggen@xythos.com]
> Sent: Friday, October 03, 2003 6:38 PM
> To: Julian Reschke; www-webdav-dasl@w3.org
> Subject: RE: issue "qsd-optional"
>
>
>
> Immediate Disagreement!  :)

Thanks for the immediate feedback.

> You hit on the problem; the supported grammar varies across scopes on
> many servers (and can be dependant on the particular installation as
> well).  In Xythos, schema can even change for elements inside a scope.
> What is the correct response, an AND of all the supported properties?
> OR?

Keep in mind that the Query Schema provides *two* pieces of valuable
information.

1. Information about optional operators
2. A set of searchable properties (and their types)

Regarding your question: if the server indeed wants to provide information
about searchable properties, then in this case it would be the set of all
properties that are searchable on *all* resources within the scope. Note
that this doesn't necessarily mean that the property must be present across
all resources. For instance, you may have a live property that only exists
on some resources (with a specific type), and doesn't exist at all on the
other resources. You could report that property as searchable.

On the other hand, a server can always choose not to return any propdesc
elements -- it's not guaranteed to be exhaustive, so an empty list is a
correct answer as well.

Also note that since the old drafts the ability was added to declare all
properties as searchable (see
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-search-00.html#rfc.is
sue.bsschema-DTD>).

> While I like the idea of query schema, in practice it quickly becomes
> useless on real world servers.  I completely disagree that the Query
> Schema will be the same for all requests and thus never need to be
> computed on the fly.  Since schemas can change across the scopes (no
> where in 2518 does it claim it can't), they would have to be dynamically
> created and possibly be useless (for the AND/OR problem I mention
> above).  Thus the only thing a DASL client can really depend on is a)
> the DAV: live properties and b) that the properties on specific resource
> are set (do a PROPFIND depth 0 to see the props on that element, then do
> a query from there if you want).

Well, it can also use the schema to detect which optional operators are
present, and use the propdesc that are returned as a hint for the user
interface (to suggest defaults).

> I believe that we cannot make the QSD mandatory as it will be a useless
> endeavor on many servers.  In fact I argued 3 years ago it should simply
> be dropped from the specification altogether (I got everyone at THAT
> meeting to agree to kill QSD for these reasons).  I still believe we
> should drop QSD as it unfortunately can't help interoperability and thus
> is not a useful feature for this first spec.

It depends on how you use QSD:

1) the information about optional operator availability should be trivial to
compute as it only depends on the software module that is executing the
query. Thus, once the code knows how the query is going to be
parsed/executed, it can answer that.

2) the set of queryable properties may indeed be hard to compute, in which
case a server can just return an empty set, and no harm is done. However,
*if* it comes up with a list, this can greatly help providing a user
interface.

Maybe the issue here is that two separate issues (query grammar discovery
and discovery of searchable properties) has been combined into a single
protocol feature?

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Friday, 3 October 2003 13:52:03 UTC