Comments on draft DASL protocol spec

Great work, Saveen!

I'm working from Jim's version of the spec for these comments:

General

Need to be precise about status codes everywhere

Will the new XML elements become part of the DAV DTD?  In any case, refer
to the DAV DTD for already-defined elements (like prop, allprop), and make
sure there's no conflict.  Like depth, which in the DAV DTD cannot take "1"
as a value, and uses "infinity" rather than "infinite".

Maybe just refer to the DAV spec for XML elements that have already been
defined, or at least state that they are also defined there.

Detail

2.3.2 If we use the definition of "query" from the requirements, we would
expect the searchrequest XML element to contain (in addition to the query
grammar) search scope, result record definition, search criteria, sort
specification, and other search attributes.

2.4 Multi-Status is 207, not 217

To comply with 2.3.1: For simplesearch, explicitly state the relationship
between the request URI and the scope

To comply with 2.5: For simplesearch, explicitly state how response relates
to PROPFIND response

6.4 "allprop" and "prop" if you want to use the elements defined in DAV.
Only property names, no values, are allowed in a prop element inside a
select element.

6.4.1 I'm not sure what this is trying to say.  I hope it's not just about
the properties defined in the DAV DTD, but rather that any property that
can be expressed in a prop element (as defined in DAV) can appear in a
select element.

6.5 Do we need both "from" and "scopelist"?

Does a "scope" element have to be a collection?  What if I have just a list
of unrelated non-collection resources that I want to search?  I thought the
requirements included that case.

6.6.1 Provide truth tables for AND, OR, NOT for three-valued logic?  Maybe
not necessary.

6.6.2 Requirements included tests for existence.  Syntax doesn't allow for
this.  Do we care?

Definition of value should be (prop | literal)

6.6.4 I agree with Jim that the client should be able to request that a
comparison be case-sensitive or not.  This actually applies not only to
contains, but to any operator that can apply to a string-valued property.

The requirements say that for content comparisons the client should also be
able to specify whether to do stemming, phonetic search, truncation, or
keyword expansion.

6.8 What the requirements said about variants was that it should be
possible to have a query be applied to all variants of a resource or to
target it to specific variants.  

There are two things that might be meant here.  One applies to the request,
one to the response.

On the request side: For content-based searches, you might want to say
"Find all resources that contain the expression "motor", but check only
their Enlish-language variants."  (Unless you have a smart search engine
that will translate "motor" for each available language variant.)

On the response side: Whether the query was based on properties or content,
you might want to specify which variants are to be included in the result set.

On the request side the query grammar would have to allow a client to
request that all variants be searched, or that the search be restricted to
certain variants.  On the response side, the response grammar would have to
provide a way for each response record to identify which variant it
represents.  

We might want to duck this requirement, or else base it as best we can on
the content negotiation section 12 of HTTP/1.1.  If we want to start from
HTTP/1.1, maybe we could limit ourselves to providing a way for the query
to specify which media type, character set, and / or language variants of
the resources are to be searched.  Similarly for the response.

5, 6.10.  I'm a little confused about the relationship between a query
grammar and a query grammar schema.  If the schema is as described in 6.10,
I would not expect it to be a property of the SEARCH request-URI.  There
might be different scopes within the jurisdiction of the request-URI that
allow different properties to be searched, or that allowed content-based
search or not.

You need some way to figure out what scope(s) within the jurisdiction of
the request-URI a schema applies to.

It also seems wrong for the property name to be the name of the query
grammar.  I expect the property name to be a URI that will get me to a
definition of the property.  So for the simplesearch schema property, I
expect it to get me to a definition of the syntax and semantics of the
schema (as in 6.10), not to the definition of the query grammar.

Requirements not addressed:

Scope within Resource
Max number of records
Paged results
Natural language queries
Redirection
Hit Highlighting


Name:		Judith A. Slein
E-Mail:		slein@wrc.xerox.com
Phone:  	(716) 422-5169
Fax:		(716) 422-2938

Xerox Corporation
Mail Stop 105-50C
800 Phillips Road
Webster, NY 14580

Received on Friday, 13 March 1998 17:09:27 UTC