W3C home > Mailing lists > Public > www-webdav-dasl@w3.org > October to December 2001

RE: DASL draft issue: identification of query grammars

From: Julian Reschke <julian.reschke@gmx.de>
Date: Sat, 15 Dec 2001 20:04:44 +0100
To: "Lisa Dusseault" <lisa@xythos.com>, <www-webdav-dasl@w3.org>
Message-ID: <JIEGINCHMLABHJBIGKBCKEIDDKAA.julian.reschke@gmx.de>
> From: www-webdav-dasl-request@w3.org
> [mailto:www-webdav-dasl-request@w3.org]On Behalf Of Lisa Dusseault
> Sent: Saturday, December 15, 2001 7:45 PM
> To: Julian Reschke; www-webdav-dasl@w3.org
> Subject: RE: DASL draft issue: identification of query grammars
>
>
>
> > 1) But why choose a format that requires out-of-band information
> > (which URI
> > is for which grammar), if it would be possible to marshall the required
> > information in the first place?
>
> I don't understand this.  What is the out-of-band information, other than
> the DASL specification itself?

What about query grammars other than those in the DASL specification?

> > Why invent a format like this, if the
> > similar REPORT method already shows a better solution? Why
> > require a client
> > to do an OPTIONS call, if deltaV/ACL already supply this kind of
> > information
> > as live properties? I'd prefer the protocol to be consistent with other
> > WebDAV extensions
>
> DASL is consistent with other WEbDAV extensions -- support for it is
> advertised in OPTIONS.

Well, it should also be in <supported-method-set> and...

> > (no, this wouldn't mean that PROPFIND is required for
> > DASL -- it just means that if PROPFIND exists, it would offer these live
> > properties).
>
> Which live properties?

...a new <supported-search-grammar-set>.

> > 2) If we want to stick with the current method, the draft must be
> > rewritten
> > to define it properly. Right now it only shows examples where the
> > namespace
> > URI and the local name have been concatenated to form a URI. This
> > only works
> > for a subset of namespace URIs.
>
> Where specifically is the problem in the draft?  Is it a problem that the
> draft says things like "The DAV:searchrequest XML element..." ? I
> agree this
> might be a little confusing, however it's just a convention for
> writing, it
> doesn't mean that "DAV:searchrequest" is a valid URI.

The problem is in the draft saying things like:

<quote>
The DASL response header indicates server support for a query grammar in the
OPTIONS method. The value is a URI that indicates the type of grammar. This
header MAY be repeated.

For example:

DASL: <http://foo.bar.com/syntax1>
DASL: <http://akuma.com/syntax2>
DASL: <FOO:natural-language-query>
</quote>

It doesn't say *how* these URIs identify a query grammar.

> I don't see any problem with the DASL: header in OPTIONS.  It states that
> the value is a URI (actually a coded-URL which means putting an
> absolute URI
> in <>), and all the examples show URIs.  E.g.:
>
> 	DASL: <DAV:basicsearch>
>
> In this case, "DAV:basicsearch" is a URI in the DAV scheme, as defined by
> this draft.

Well, yes. But when I want to submit a query using the searchrequest
element, I'll have to find the matching XML element name? Is it<basicsearch
xmlns="DAV:" />? Or is it <search xmlns="DAV:basic" />?

This isn't a problem for non-XML-based grammars, but XML based query
grammars are identified by an XML element name (which has no canonical
mapping to a URI).

So my suggestion is:

- keep query grammar discovery through OPTIONS headers, but clarify the
language
- require that servers that do support PROPFIND and the live property
<supported-method-set> will include "SEARCH" as method
- require that servers that do support PROPFIND supply a live property
similar to deltaV's <supported-report-set>.

Julian
Received on Saturday, 15 December 2001 14:05:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 22 March 2009 03:38:07 GMT