- From: Kevin Wiggen <wiggs@xythos.com>
- Date: Sat, 23 Oct 1999 16:39:05 -0700
- To: www-webdav-dasl@w3.org
Some more questions 1) I see Dasl does not have a meeting planned for IETF Washington. Should there be one? Does anyone want to meet on the side to discuss issues, implementation, integration, etc? 2) What should a server return if a client asks for a valid query to which there are no results. Should it return a 207 with a empty <d:multistatus/>, or should some other response code (404 possibly) be give? 3) DAV:datatype has dateTime.iso8601tz as its datatype for dates. This works great, is easy and translatable. But, should requests for the <d:getlastmodified> property be submitted in HTTP-DATE format? I think this is more work, but is easy to accommodate. If we make all dates be submitted in dateTime.iso8601tz format, will anyone find it weird that you ask for the last modified date in one format, but get the response in a different format? 4) I don't believe the discussion on QSD is very good in the spec. What is the depth on a QSD? Can the depth only be 0? If it is infinity, does the server try to AND or OR all the possible properties together into one response, or does it give a response for each node it finds (much like a <d:propname> in PROPFIND)? 5) I think that the QSD should be moved to PROPFIND. Right now it is kind of hacked into the SEARCH method. What you are really asking for is what properties exist, and what can I do to them. I think a new Header should be added to PROPFIND, this will turn the PROPFIND request from a typical PROPFIND to a QSD. Since a client can ask the server whether it supports SEARCH, it can then know whether or not it will get the appropriate response from a QSD request to PROPFIND. I realize this is tough for people implementing with search arbiters, but I think that once searching is on, it should be easy for a client to ask a resource and it's children what properties it supports and how they are queried. 6) What is the default depth for a SEARCH? Maybe its there, but I have looked for it a few times and could never find it :) 7) When returning a 507, result set truncation, why does the example have an extra <d:response> for the queried request which has status of 507? Won't the client understand from the 507 that the server limited the number of responses? This seems like extra unnecessary use of the pipe. 8) Why don't <d:like>'s allow for case insensitive searching? 9) Dead Property's values can contain xml. This causes Webdav servers to do special processing with the xml values if they contain new namespaces. (If property <d:foobar> value = <x:fee>fdsg</x:fee> where x is not defined anywhere else, the server must do special processing to store a correct value for the dead property value.) This causes the same sort of processing to go on if the following is sent to the server <d:eq><d:prop><d:foobar></d:foobar></d:prop> <d:literal><x:fee xmlns:x="http://www.xythos.com">value</x:fee></d:literal></d:eq> Since this needs to be done anyway in order to support queries on dead properties, why can't a client simply request: <d:eq><d:prop><d:resourcetype></d:prop> <d:literal><d:collection/></d:literal></d:eq> It uses <d:literal> loosely, but is quite easy to accomplish on the server, and makes <d:iscollection> useless. Also are there any thoughts on what happens if <d:iscollection> is used with <d:lt>? It seems strange to allow for this (as each server will answer differently depending on their implementation). Why is <d:iscollection> (if it is needed at all), not defined as <!ELEMENT iscollection (prop)> You don't need a 1/0 value as you can always wrap it in a <d:NOT> if you want the opposite. 10) Has anyone given any thought as to the possibility or implementation of using the 2 lock live properties in a where clause? Thanks, Kevin
Received on Saturday, 23 October 1999 19:45:51 UTC