- 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>
> 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 UTC