More Questions on Dasl

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