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?

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

> (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?

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

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.

Lisa

Received on Saturday, 15 December 2001 13:46:42 UTC