RE: comment on DASL draft issue: qsd pseudo property

Hi,

here's an attempt to rewrite the section with a new marshalling format
similar to my last week's proposal. Please review.

4  Query Schema Discovery: QSD

Servers MAY support the discovery of the schema for a query grammar.

The DASL response header and the DAV:supported-query-grammar-set property
provide provides means for clients to discover the set of query grammars
supported by a resource. This alone is not sufficient information for a
client to generate a query. For example, the DAV:basicsearch grammar defines
a set of queries consisting of a set of operators applied to a set of
properties and values, but the grammar itself does not specify which
properties may be used in the query. QSD for the DAV:basicsearch grammar
allows a client to discover the set of properties that are searchable,
selectable, and sortable. Moreover, although the DAV:basicsearch grammar
defines a minimal set of operators, it is possible that a resource might
support additional operators in a query. For example, a resource might
support a optional operator that can be used to express content-based
queries in a proprietary syntax. QSD allows a client to discover these
operators and their syntax. The set of discoverable quantities will differ
from grammar to grammar, but each grammar can define a means for a client to
discover what can be discovered.

In general, the schema for a given query grammar depends on both the
resource (the arbiter) and the scope. A given resource might have access to
one set of properties for one potential scope, and another set for a
different scope. For example, consider a server able to search two distinct
collections, one holding cooking recipes, the other design documents for
nuclear weapons. While both collections might support properties such as
author, title, and date, the first might also define properties such as
calories and preparation time, while the second defined properties such as
yield and applicable patents. Two distinct arbiters indexing the same
collection might also have access to different properties. For example, the
recipe collection mentioned above might also indexed by a value-added server
that also stored the names of chefs who had tested the recipe. Note also
that the available query schema might also depend on other factors, such as
the identity of the principal conducting the search, but these factors are
not exposed in this protocol.

4.1  Additional SEARCH semantics

Each query grammar supported by DASL defines its own syntax for expressing
the possible query schema. A client retrieves the schema for a given query
grammar on an arbiter resource with a given scope by invoking the SEARCH
method on that arbiter with that grammar and scope and with a root element
of DAV:query-schema-discovery rather than DAV:searchrequest.

Marshalling:

The requst body MUST be DAV:query-schema-discovery element.

<!ELEMENT query-schema-discovery ANY>
ANY value: XML element defining a valid query


The response body takes the form of a RFC2518 DAV:multistatus element, where
DAV:response is extended to hold the returned query grammar inside a
DAV:query-schema container element.

<!ELEMENT response (href, ((href*, status)|(propstat+)),
  query-schema?, responsedescription?) >
<!ELEMENT query-schema ANY>


The content of this container is an XML element whose name and syntax depend
upon the grammar, and whose value may (and likely will) vary depending upon
the grammar, arbiter, and scope.

4.1.1  Example of query schema discovery

In this example, the arbiter is recipes.com, the grammar is DAV:basicsearch,
the scope is also recipes.com.

 >> Request:

SEARCH / HTTP/1.1
Host: recipes.com
Content-Type: application/xml
Content-Length: xxx

<?xml version="1.0"?>
<query-schema-discovery xmlns="DAV:">
  <basicsearch>
    <from>
      <scope>
        <href>http://recipes.com</href>
      </scope>
    </from>
  </basicsearch>
</query-schema-discovery>

 >> Response:

HTTP/1.1 207 Multistatus
Content-Type: application/xml
Content-Length: xxx

<?xml version="1.0"?>
<multistatus xmlns="DAV:">
  <response>
    <href>http://recipes.com</href>
    <status>HTTP/1.1 200 OK</status>
    <query-schema>
      <basicsearchschema>
        (See section "Query schema for DAV:basicsearch" for
        the actual contents)
      </basicsearchschema>
    </query-schema>
  </response>
</multistatus>


The query schema for DAV:basicsearch is defined in Section 5.19.





> -----Original Message-----
> From: www-webdav-dasl-request@w3.org
> [mailto:www-webdav-dasl-request@w3.org]On Behalf Of Julian Reschke
> Sent: Monday, June 17, 2002 11:17 AM
> To: Jim Davis; www-webdav-dasl@w3.org
> Subject: RE: comment on DASL draft issue: qsd pseudo property
>
>
>
> Hi,
>
> is everybody happy with this format? In which case I'll rewrite
> the section
> in the draft.
>
> Julian
>
> > -----Original Message-----
> > From: www-webdav-dasl-request@w3.org
> > [mailto:www-webdav-dasl-request@w3.org]On Behalf Of Julian Reschke
> > Sent: Monday, June 10, 2002 9:02 AM
> > To: Julian Reschke; Jim Davis; www-webdav-dasl@w3.org
> > Subject: RE: comment on DASL draft issue: qsd pseudo property
> >
> >
> >
> > Here's an attempt to avoid the usage of pseudo-properties (feedback
> > appreciated):
> >
> > 1) Query:
> >
> > Instead of:
> >
> > SEARCH / HTTP/1.1
> > Host: recipes.com
> > Content-Type: application/xml
> > Content-Length: xxx
> >
> > <?xml version="1.0"?>
> > <searchrequest xmlns="DAV:">
> >   <basicsearch>
> >     <select>
> >       <prop>
> >         <queryschema/>
> >       </prop>
> >     </select>
> >     <from>
> >       <scope>
> >         <href>http://recipes.com</href>
> >       </scope>
> >     </from>
> >   </basicsearch>
> > </searchrequest>
> >
> > use
> >
> > SEARCH / HTTP/1.1
> > Host: recipes.com
> > Content-Type: application/xml
> > Content-Length: xxx
> >
> > <?xml version="1.0"?>
> > <grammar-discovery xmlns="DAV:">
> >   <grammar>
> >     <basicsearch/>
> >   </grammar>
> >   <scope>
> >     <href>http://recipes.com</href>
> >   </scope>
> > </grammar-discovery>
> >
> > Note: we change the name of the document element to distinguish from a
> > search request. An alternative approach would be to use a
> REPORT, but that
> > would introduce a dependancy on other RFCs I'm sure many won't like.
> >
> > 2) Result:
> >
> > Instead of:
> >
> > HTTP/1.1 207 Multistatus
> > Content-Type: application/xml
> > Content-Length: xxx
> >
> > <?xml version="1.0"?>
> > <multistatus xmlns="DAV:">
> >   <response>
> >     <href>http://recipes.com</href>
> >     <propstat>
> >       <prop>
> >         <queryschema>
> >           <basicsearchschema>
> >             (See section "Query schema for DAV:basicsearch" for
> >             the actual contents)
> >           </basicsearchschema>
> >         </queryschema>
> >       </prop>
> >       <status>HTTP/1.1 200 OK</status>
> >     </propstat>
> >   </response>
> > </multistatus>
> >
> > Use:
> >
> > HTTP/1.1 207 Multistatus
> > Content-Type: application/xml
> > Content-Length: xxx
> >
> > <?xml version="1.0"?>
> > <multistatus xmlns="DAV:">
> >   <response>
> >     <href>http://recipes.com</href>
> >     <queryschema>
> >        <basicsearchschema>
> >          (See section "Query schema for DAV:basicsearch" for
> >          the actual contents)
> >       </basicsearchschema>
> >     </queryschema>
> >     <status>HTTP/1.1 200 OK</status>
> >   </response>
> > </multistatus>
> >
> > So we need to extend the response element, but that's still better than
> > introducing pseudo-properties.
> >
> >
> >
> >
>

Received on Sunday, 23 June 2002 15:33:20 UTC