- From: Kevin Wiggen <wiggs@xythos.com>
- Date: Tue, 12 Oct 1999 10:53:12 -0700
- To: <www-webdav-dasl@w3.org>
- Message-ID: <LNBBKDGPNJMOJNOBHLLMGEBACDAA.wiggs@xythos.com>
I have read threw a number of the old posts, and I apologize if I am bringing up old things.... 1) I agree there needs to be a way of getting next set, previous set for results. I argue whether the protocol itself should help implement it (with query id's etc), but some functionality needs to be put in. 2) Dates. The spec is silent on all date type of properties. I am assuming that since RFC2518 states that creationdate is ISO8601 Date and Time profile, so dates in the query (where clause) must be in this format. getlastmodified is a HTTP-date (never really understood why these where different), and thus queries which contain this property must be in this format. I also assume that a "LIKE" on a date will just do a simple conversion of the DATE to a String and then compare. This is usually useless, but nonetheless so are most conversions. OR are we going to define a date format mask which we should use to convert our date with in order to do the "LIKE" (I guess we could use the ISO8601 and HTTP-date as format masks and do a string compare on that). 3) Character set issues. I believe there are going to be character set issues using the Contains clause, and its not DASL's fault. When doing character sets using properties, there should not be a problem. Character Sets Properties - Since the character set of the XML is given, servers can convert the request into the character set that the server internally uses and do any compares. This should work without problem (assuming the server uses Unicode (or some superset of the possible character sets) of some sort for its internal storage. Character Sets for Contains - Unfortunately the server has no control over what the character set the files are. And when files are PUT or uploaded to the server using Webdav clients today (well MS), the character-set is not sent. Without being sent the character set of the file, it could be hard to search it. 4) >> A way of returning a result count would be useful. This can be very expensive for the server. Although most servers can give "of at least" type of responses. If result count is added to the spec, I propose that a server can give a "of at least" type of response. 5) >> A way of stopping a query that is already running is very important. Can't the client simply close the connection. Then its up to the server to stop the query. Kevin
Received on Tuesday, 12 October 1999 13:58:14 UTC