initial proposal for structure criteria

This message presents an initial design for a structure criteria that
is sufficient to implement all the scenarios in the DASL scenarios
document. 

I assumes that the reader already understands the DAV object model.
Briefly, this model is a tree, where nodes are either 'elements' or
'strings'.  The root may be of either type.  An element has a label, which
is a URI, and it has a set of children, which may be empty.  A string is
just a string, and never has children.  The root of the tree may be of
either type, and leaves may be of either type.

1. Syntax

In the syntax below, EXPR is a meta-syntactic variable that stands for (and
should be replaced by) and | or | not | eq | lt | lte | gt | gte | like |
isnull

New operators:

1.1 dav:child-elem

Name: child-elem
Description: True of an element if it has at least one immediate child
 that is an element and for which the enclosed expression is also
 true.  This is an optional operator.

<!ELEMENT child-elem (prop|immediate) EXPR >

If the first element is dav:prop, the test applies to the property value.
If it is dav:immediate, then the operator must occurs within the second
clause of an enclosing child-elem operator.  In this case the test applies
to the same element that the enclosing child-elem operator is testing (that
is, it examines the immediate children of that element.)

1.2 dav:child-str

Name: child-str
Description: True of an element if it has at least one immediate child
 that is a string and for which the enclosed expression is also
 true.  This is an optional operator.

<!ELEMENT child-str (prop|immediate) EXPR >

1.3 dav:label

Name: label
Description: in an expression within a child-elem, has the value of
the label of the element

<!ELEMENT label EMPTY >

1.4 dav:string

Name: string
Description: in an expression within a child-str, has the value of the
string.

<!ELEMENT string EMPTY >

1.5 dav:immediate

Name: immediate
Description: indicates that the operator applies to the content of the
element being tested.

<!ELEMENT immediate EMPTY>


2. Examples:

2.1 This criteria selects those resources that are collections:

<d:child-elem>
  <d:prop><d:resourcetype/></d:prop>
  <d:eq><d:label/><d:literal>dav:collection</d:literal></d:eq>
</d:child-elem>

2.1 This criteria selects resources where anyone named "Joe" has an
exclusive write lock.

This requires searching the lockdiscovery property for an activelock
element that has 
 * a child lockscope that has an element child labeled dav:exclusive
 * a child labeled locktype that has an element child labeled dav:write
 * a child labeled owner that has a string child that matches
    the pattern %Joe%

<d:child-elem><d:prop><d:lockdiscovery/></d:prop>
 <d:and>
   <d:eq><d:label/>
         <d:literal>dav:activelock</d:literal></d:eq>
    
   <d:child-elem><d:immediate/>            
     <d:and>                           
        <d:eq><d:label/>
              <d:literal>dav:locktype</d:literal></d:eq>
        <d:child-elem><d:immediate/>
          <d:eq><d:label/>
                <d:literal>dav:write</d:literal></d:eq>
        </d:child-elem>
     </d:and>
   </d:child-elem>

    <d:child-elem><d:immediate/>
       <d:and>
        <d:eq><d:label/>
              <d:literal>dav:lockscope</d:literal></d:eq>
        <d:child-elem><d:immediate/>
          <d:eq><d:label/>
                <d:literal>dav:exclusive</d:literal></d:eq>
        </d:child-elem>
       </d:and>
    </d:child-elem>

    <d:child-elem><d:immediate/>
       <d:and>
        <d:eq><d:label/>
              <d:literal>dav:owner</d:literal></d:eq>
        <d:child-str><d:immediate/>
          <d:like><d:string/>
                  <d:literal>%Joe%</d:literal></d:like>
        </d:child-str>
      </d:and>
    </d:child-elem>

 </d:and>
</d:child-elem>

2.3 Multiple authors

This example assumes a hypothetical author property where the value is a
set of person tags.  Such a property, on the wire, might look like

<x:author>
 <x:person>Sinatra, Frank</x:person>
 <x:person>Zappa, Frank</x:person>
 <x:corporate>The Franklin Institute</x:corporate>
</x:author>

Here, the first two elements are names of persons, the third is the name of
a "corporate author" (the term used in librarianship for works written by
an institution).

It is very probable that properties with such forms will be used with
WebDAV.  It is the most reasonable way to express the Dublin Core property
set, which is widely used to express metadata in the digital library
community, and (as I understand it) the current draft proposal for version
labels would use it.  It is the only interoperable way to express "list
valued" data.

Find resources where written by person whose name matches White%

<d:child-elem><d:prop><x:author/></d:prop>
 <d:and>
   <d:eq><d:label/><d:literal>x:person</d:literal></d:eq>
   <d:like><d:string/><d:literal>white%</d:literal></d:like>
 </d:and>
</d:child-elem>

   
3. Other syntactic changes

The syntax proposed here requires a few small extensions to other
syntax of DASL basicsearch.

3.1  The syntax of lt, lte, gt, gte, eq, and like is changed from

<!ELEMENT eq (prop, literal) >

to 

<!ELEMENT eq ((prop|label|string), literal) >

3.2  The syntax of where, and, or, amd not is changed to allow use of
child-elem and child-str

4. Discussion

The criteria proposed here are deliberately limited in expressive power in
the hope it will also make it easy to implement.

In particular

1) The elem-child and elem-string operators test only the immediate
children of an element, not all children at any recursive depth

2) There is no provision for variable binding.  All tests apply only to the
immediate node under consideration.  Thus for example one can not construct
a criteria that finds all resources with two different locks taken out by
the same individual.

At the same time, the proposal allows all the existing DASL operators to be
applied to both the labels of elements and the strings with the structure.
While I have my doubts about the usefulness of a pattern match against an
element label, I can see no reason to rule it out.

These criteria are also extensible.  In particular, one could support
arbitrary depth searches of children by defining a new modifier to replace
dav:immediate.  [I don't think we should use dav:depth, because if refers
to depth in a *collection* rather than depth in a *property structure*.
Although both are trees, that's about all they have in common.]

best regards

Jim

Received on Sunday, 30 August 1998 16:43:36 UTC