RE: more detailed version of query schema for simplesearch

Jim:

This is good. It's about time we started to flesh this
area out. Thanks for floating your proposal.
I have a few comments.

(1) To advertise the capabilites of the properties
supported by the collection, in your proposal,
the property names may be repeated multiple times.
I think this is not the best design. I would rather
see a syntax where the property name is mentioned
once, and the capabilities of the property (i.e.,
selectable, sortable, orderable) come immediately 
afterward. To me, this would be more intuitive.
And it would be more amenable to
adding capabilities to the properties in the
future, would be less redundant, would tend
to reduce the size of the advertising response, etc.

Perhaps one way to do this is with attributes,
one for each capability. The default would be to not
have the capability unless it is explicitly
mentioned. Examples:

    <D:author/ t:selectable="t" t:searchable="t" t:orderable="t" >

    <D:amount/ t:selectable="t" >

 
(2) The collection must advertise the operators that it supports
as well as the properties. (Your current proposal is limited to
just the properties.)

(a) I assume there will be a small set of
operators (less than or equal to the set of operators
already in the draft) that are required, and all other
operators in 1.0 and future versions of the spec. will be
optionally supported. 

DIGRESSION:
Personally, I think that requiring OR, NOT, and CONTAINS is an
interesting topic for discussion. I know of extremely significant 
systems that don't provide any of these. They just provide
AND, the six comparison operators, and a pattern
match operator equivalent to the SQL LIKE operator.
By making more than just these operators required,
we may be requiring work in the API and query engine of such
systems, thereby raising the barrier to entry, and
making the standard less broadly applicable.
OR and NOT wouldn't be nearly as big a deal to add to
such a system as CONTAINS would, because for CONTAINS,
the vendor would have to strike a deal with a full text vendor,
integrate with the full text engine, require the full text
retrieval capability in every WebDAV capable system, etc.
END DIGRESSION

(b) There is value in requiring the
collection to advertise the mandatory operators as well
as the optional operators it supports. The value is that
the collection can then express restrictions on the
form of the operands that it imposes. For example,
as currently specified in the draft, the boolen operators
AND, OR, and NOT take expressions for any operand.
(If an operand can be an expression, it can obvioiusly
also be a property name or a literal.) However, the
six comparison operators currently in the draft require the
first operand to be limited to a property name, and
the second operand to be limited to a literal.

The following approach would address all the issues:

The collection would be required to advertise
the operators it supports by simply listing their
names. (The names will be in the 1.0 and later specs.)
By default, all operands to any operator can be
expressions. (That means that the operand can
be an operator, a property URI, or a literal.)
If any operand of an operator is less general
that "expression", the limitation of the form of the operands
must be given immediately following the operator
name. The restrictions would be ordered positionally
by operand occurrence.

For example, the collection could advertise
that it supports the "and" operator by just
giving its name:

    and

This is equivalent to all operands being allowed
to be expressions:

    and ( expr expr )

(I don't care much whether we use the exact above
syntax, or XML tags, or whatever. I'm just trying
to illustrate the advertising principle here. Maybe
we could use XML tags and optional attributes
for the restrictions.)

Since "and" is N-ary, all the operands after the
second one are limited to the form of the second
operand's restriction.

To advertise a basic "less than" operator, lt:

    lt ( property literal )

To advertise a fully general "less than" operator:

    lt 

or

    lt ( expr expr )

A collection supporting only the funcionality
currently in the spec. could advertise its
operators as follows:

    and or not lt (property literal) gt (property literal)
    lte (property literal) gte (property literal)
    eq (property literal) ne (property literal)
    contains

If you want to make this look more XML-ish,
be my guest.


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 Thursday, 25 June 1998 15:11:42 UTC