- From: Lisa Dusseault <lisa@xythos.com>
- Date: Sat, 15 Dec 2001 10:44:42 -0800
- To: "Julian Reschke" <julian.reschke@gmx.de>, <www-webdav-dasl@w3.org>
> 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