RE: more detailed version of query schema for simplesearch

I would like to examine the ramifications of the grammar
proposed below as far as processing on the client
and server are concerned.

I assume that there is a table of properties, i.e., an array of
structures, one for each property, and this is true 
on both the client and the server side. 
(There might also be an array of pointers to the 
structures that is a hash table on property name in order
to accelerate access to the properties via name. Their might
also be a link field that links all the selectable properties, etc.,
but if you're willing to do linear search, a simple array
of structures would suffice.)

The server code would look like this:

    emit the searchable opening tag;
    for each searchable property:
        emit the property;
    end for
    emit the searchable closing tag;
    emit the selectable tag opening tag;
    for each searchable property:
        if property is selectable then
            emit the property name;
        end if
    end for
    emit the selectable closing tag;
    emit the sortable opening tag;
    for each searchable property:
        if property is sortable then
            emit the property name;
        end if
    end for
    emit the sortable closing tag;

The client would look like this:

    for each searchable property:
        add a structure to the array, and mark the
            property as searchable but not selectable or
            sortable;
    end for
    get the selectable tag;
    get the first tag after the selectable tag;
    if the tag is the empty "allprop" tag, then
        for each property in the array:
            mark the property as selectable;
        end for
    elif
        for each property in the list of properties
            starting with the property we already have:
            get the property name;
            look up the property in the array of structures.
            if not found,
                fatal error. server has a bug;
            end if
            mark the property as selectable;
        end for
     end if
    get the sortable tag;
    get the first tag after the sortable tag;
    if the tag is the "allprop" tag, then
        for each property in the array:
            mark the property as sortable;
        end for
    elif
        for each property in the list of properties starting
             with the one we already have:
            get the property name;
            look up the property in the array of structures.
            if not found,
                fatal error, server has a bug;
            end if
            mark the property as sortable;
        end for
     end if

In the alternative grammar I proposed, the properties
are listed only once, with XML attributes giving their
characteristics.
   
The server code for the alternative grammar would look like this:

    emit the opening tag;
    for each property:
        emit the "<" and property name;
        if property is selectable then
            emit the selectable attribute;
        end if
        if the property is sortable then
             emit the sortable attribute;
        end if
        emit the ">";
   end for
   emit the closing tag

The client code would look like this:

    for each property:
        add the property to the array of structures,
            initializing its name;
         while there are attributes for this property:
             if attribute = "selectable" then
                 mark the property as selectable;
             elif attribute = "sortable" then
                 mark the property as sortable;
             else
                 /* I don't understand this attribute, so ignore it */
             end if
        end while
    end for
             
Clearly, the code is less of a bother to write for the
alternative grammar, especially on the client side.
It is also markedly more efficient on the client side,
because the proposed grammar has to look up
each selectable and sortable property but the
alternative doesn't do any lookups.
The client side is where we want to be easiest on the
programmers, I would think. Note also that the
grammar below creates the possibility for the
server code to have a bug wherein it emits a
property in the selectable or sortable list
that wasn't mentioned in the searchable list,
and that the client has to write code for this
even if no server ever has such a bug.

My conclusion is the same -- I think the alternative
grammar is a better design.

Alan Babich

> -----Original Message-----
> From:	Jim Davis [SMTP:jdavis@parc.xerox.com]
> Sent:	June 20, 1998 7:25 PM
> To:	www-webdav-dasl@w3.org
> Subject:	more detailed version of query schema for simplesearch
> 
> 7.18 Query Schema for DAV:simplesearch 
> 
> The DAV:simplesearch grammar defines a search criteria that is a
> Boolean-valued expression, and allows for an arbitrary set of
> properties to
> be includes in the result record.  The result set may be sorted on a
> set of
> property values.  Accordingly the DTD for schema discovery for this
> grammar
> allows the server to express:
> * the set of properties that may be searched, with associated
> datatypes
> * the set of properties that be be selected in the result record
> * the set of properties that may be sorted
> 
> 7.18.1 DTD for  simplesearch query schema discovery
> 
> <!ELEMENT simplesearchschema	(searchable, selectable, sortable)>
> <!ELEMENT searchable			(prop?) >
> <!ELEMENT selectable			(prop|allprop|searchable)*>
> <!ELEMENT sortable
> (prop|allprop|searchable)*>
> 
> The DAV:searchable element holds a list of properties advertised to be
> searchable.  A server MUST allow a search of any property included in
> the
> list, and it MAY allow searches of other properties not listed.
> Allowing a
> search does not mean that the property is promised to be defined on
> every
> resource, it only indicates the servers willingness to check.
> 
> The DAV:selectable element holds a list of properties that may be used
> in
> the DAV:select clause.  The value DAV:allprop means that any defined
> property may be selected.  The value DAV:searchable means that all
> searchable properties may also be selected.  
> 
> The DAV:sortable element holds a list of properties that may be used
> in the
> DAV:sortby clause.  The value DAV:allprop means all properties may be
> used.
>  The value DAV:searchable means that all searchable properties may be
> used.
> 
> 7.18.2 Example of Query Schema for DAV:simplesearch
> 
> <?xml:namespace ns="DAV:" prefix="D">
> <?xml:namespace ns="urn:uuid:C2F41010-65B3-11d1-A29F-00AA00C14882/"
> prefix="t"?>
> <?xml:namespace ns="http://dublin.org/dc/" prefix="C">
> <D:simplesearchschema>
>   <D:searchable>
>     <D:prop>
>       <D:getcontentlength/ t:dt="t:Int">
>       <D:getcontenttype/>
>       <D:creationdate/ t:dt="t:dateTime.iso8601tz">
>       <D:displayname/>
>       <D:getcontentlanguage/>
>       <D:getlastmodified/>
>       <C:author/>
>     </D:prop>
>   </D:searchable>
>   <D:selectable>
>     <D:searchable/>
>     <D:prop>
>       <C:editor/>
>       <C:coverage/>
>       <C:cost/>
>     </D:prop>
>   </D:selectable>
>   <D:sortable>
>     <D:prop>
>       <D:getcontentlength/>
>       <D:rank/>
>       <D:creationdate/>
>     </D:sortable>
>   </D:sortable>
> </D:simplesearchschema>
> 
> This response lists seven properties the server will search on.  All
> of
> them are selectable, and three additional properties may be selected
> as
> well.  The server will sort only on the properties DAV:rank,
> DAV:getcontentlength, and DAV:creationdate.

Received on Friday, 26 June 1998 18:42:42 UTC