RE: Scenario Examples

In my previous post I gave examples of queries for Rick's scenarios. In this
mail I will identify on problem with the simplesearch grammar and propose
several solutions. I will provide a few the pros & cons for each proposal. 

The Scenario: A very simple "file browsing" scenario is to get a
hierarchical list of collections ("folders") on a server. Only the data
involving the folders is of interest, not data about the files within the
folders. The simplesearch grammar can address the recursion issue. 

The Problem: However there is no means to address the "where" condition:
namely, what is the expression that identifies a resource as being a
collection or not?

The dav:resourcetype property contains the needed information, of course.
However, the value of this property is not a simple string or boolean value,
it is an arbitrarily complex chunk of XML. None of the operators currently
defined can be used to evaluate such a value. However there are several
possible solutions.

--------------------

1 - create an operator that allows search criteria to deal with arbitrarily
complex xml

pros: 
- this would solve the problem for any conceivable property

cons: 
-a big work item (we would essentially be defining a complete XML query
syntax)
-a high bar of entry for a server - it says all servers must then be able to
do very complicated searches on properties

--------------------

2 - create an operator that has *some* smarts about XML. Such an operator
could be called "xmlcontains" and returns true if a property contains as an
immediate child, some element name

The <where> might look like this:

	<where>
		<xmlcontains> 
			<prop> <resourcetype/> </prop>
			<value> <collection/> </value>
		</xmlcontains>
	</where>

pros:
- this solves the problem for the scenario and for properties used like
resourcetype

cons:
- the bar of entry is lower but still "halfway" up there. The server still
has to be very smart about XML
- more complex queries are not possible for arbitrary XML (Naturally. This
is a simplified operation.)

--------------------

3 - create an operator whose *sole purpose* is to determine whether a
resource is a collection or not. 

example:
	<where>
		<iscollection/>
	</where>

pros:
-very simple to implement & describe
-very low bar of entry -- this operator would be translated to whatever
operation the server understood to mean "is this a collection" For example
on a simple filesystem DAV implementation it just checks some attribute bit
on a file.

--------------------

4 - create a *dynamic* property whose purpose is to determine whether a
resource is a collection or not.

example:
	<where>
		<eq>
			<iscollection/>
			<literal t:dt="boolean">1</literal>
		</eq>
	</where>

pros:
solves the problem

cons:
-This property presumably only exists during a search? Could someone
PROPFIND this property? Is it "selectable"?

So those are the four proposals for a solution to this problem. I favor 3
and 4. 

Thanks,
Saveen

Received on Tuesday, 30 June 1998 15:42:25 UTC