Structure criteria for DASL queries

The purpose of this message is to make (or reopen) the case for
defining a structure criteria (also called "structured query") in
DASL.

0. Introduction/Background

In the DAV object model, the value of a property is a tree.  A node in the
tree may be one of two types, either an "element" or a "string". Only an
element node may have children, a string node never does. String nodes are
thus found only at the leaves of the tree.  The root may be of either type,
but if it is a string, then the property is "flat". An element also has a
label, which is a URI.

Note that the object model is not XML, rather XML is just the format on the
wire for transmitting such content.

1. Definition

structured value: a property value that is not a string.  By this
definition, all values are either string or structured.

structure criteria: a query criteria that can test a property value that is
structured.  The current definitions for criteria operators (e.g. eq, lt,
like) are defined only for strings.

2. Motivation

Several of the scenarios for DASL imply criteria that refer to structure.
These include:

 * resources that have been locked for more than 1 week.
 * resources that are collections.

One could also imagine (though the scenario document does not mention)

 * resources write locked by Joe
 * resources that support shared locks

In addition, the "document type" example in the Site Navigation scenario
might need a structure criteria, depending whether this (hypothetical)
property has a structured value.

At least three of the DAV defined properties (contenttype, lockdiscovery,
and supportedlock) have structured values.  Current DASL has no way to test
these.  The protocol defines an ad-hoc property dav:iscollection, which
allows it to test whether a resource is a collection, but this is not the
same as testing the resourcetype property itself.  Aside from that (which
is a mere technicality), the real problems with this approach (define an
ad-hoc property that 'shadows' the structured value) are

1) It does not scale well when new structured properties are added.
Consider that the Advanced Collection team has proposed at least two new
structure properties, for example.

2) It is unworkable for structured values with repeated elements. Suppose,
for example, one wishes to determine whether "Joe" is holding a lock on a
resource.  You might think that you could define a 'shadow' property
"lockowner" which holds the value of the owner element within the
lockdiscovery, but unlike resourcetype, there can be a potentially
unlimited number of locks on a resource (perhaps not more than one
exclusive lock, but surely more than shared lock).

I conclude that such criteria are desirable.

At the least, I think it should go into the requirements document, and I
think it should be mandatory, as there seems to be no way to meet all the
scenarios without it.

I see several possible objections to defining such a criteria:

1) It is too hard to define.

We don't know until we try.  It may be easier than you think.

2) It is too expensive to implement.

We don't know until it's defined.  If so, it can be made optional.

3) Someone else is already doing it.

Possibly so, but who?  I can well believe someone is defining an XML query,
but this might not necessarily fit the needs of the WebDAV object model.
Remember, the WebDAV object model is NOT XML.  Second, it's not clear that
that other group or groups has the same schedule we do.  If as I claim,
structure criteria is mandatory for DASL's success, we may not want to wait
for them, and we may not want our protocol held hostage to a design we
don't control and which might change unexpectedly.  Finally, with all due
humility, it's not clear that we couldn't do just as well, or even better,
_especially_ if we also create some running code to go along with the design.

A followup message makes some observations about the DAV object model that
might lead to a useful query syntax.

[I ask anyone who replies to this message that if you include the body of
the message in the reply, please edit it to the smallest length sufficient
to provide context.]

Best regards

Jim


------------------------------------
http://www.parc.xerox.com/jdavis/
650-812-4301

Received on Friday, 28 August 1998 13:07:16 UTC