- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Sun, 23 Jun 2002 21:32:39 +0200
- To: "Julian Reschke" <julian.reschke@gmx.de>, "Jim Davis" <jrd3@alum.mit.edu>, <www-webdav-dasl@w3.org>
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