The identifier is a name for the issue (and is unique within this document).
The type of issue is one of:
The status of the issue is one of:
The reference is an indication of where the issue was first raised.
The description is a succinct overview of the issue.
The resolution describes the specification change that resolves the issue.
| Identifier | Type / Status | Reference and Description | Proposed Resolution / Latest Change |
|---|---|---|---|
| auth48 |
edit open |
julian.reschke@greenbytes.de, 2008-10-10: Umbrella issue for changes made during the RFC Editor's AUTH48 period. | latest change in revision latest |
| edit |
edit open |
julian.reschke@greenbytes.de, 2004-07-05: Umbrella issue for editorial fixes/enhancements. | latest change in revision latest |
| Identifier | Type / Status | Reference and Description | Resolution / Latest Change |
|---|---|---|---|
| 1.3-apply-condition-code-terminology |
change closed |
julian.reschke@greenbytes.de, 2003-10-07: (Umbrella issue that will be left open until RFC3253 condition terminlogy is used throughout the document) | in revision 10: Closed for now (avoid major editorial changes for now). |
| 1.3-import-condition-code-terminology |
change closed |
Reference: <http://lists.w3.org/Archives/Public/www-webdav-dasl/2003JanMar/0042.html> julian.reschke@greenbytes.de, 2003-10-05: Import RFC3253 pre/postcondition code terminology and use it throughout the document to identify conditions. |
in revision 05: Section 2.5 rewritten. |
| 1.3-import-DTD-terminology |
change closed |
Reference: <http://lists.w3.org/Archives/Public/www-webdav-dasl/2003JulSep/0012.html> julian.reschke@greenbytes.de, 2003-09-27: Import DTD usage notes from ordering spec. |
in revision 05: Done. |
| 1.3-import-requirements-terminology |
change closed |
julian.reschke@greenbytes.de, 2003-10-06: Import terminology from DASLREQ. | in revision 05: Done. |
| 2.4-multiple-uris |
change closed |
julian.reschke@greenbytes.de, 2003-09-09: However, the set of URIs for a given resource may be unlimited due to possible bind loops. Therefore consider to report just one URI per resource. | in revision 10: Allow servers which can do that to report just one. |
| 3.2-listsyntax |
edit closed |
julian.reschke@greenbytes.de, 2008-06-25: Clarify what HTTP-style list syntax in headers means; adjust examples. | in revision 16: Done. |
| 5.1-name-filtering |
change closed |
Reference: <http://lists.w3.org/Archives/Public/www-webdav-dasl/2003JulSep/0002.html> julian.reschke@greenbytes.de, 2003-09-08: This query grammar supports properties and content, but not conditions on URL elements (such as the last segment that many WebDAV implementations treat as "file name"). Discuss possible extension such as adding name filters to the scope, or adding a specific operator. Martin.Wallmer@softwareag.com, 2003-11-11: Specific proposal to add this feature as scope restriction, see <http://lists.w3.org/Archives/Public/www-webdav-dasl/2003OctDec/0035.html>. Martin.Wallmer@softwareag.com, 2003-11-25: Updated proposal: <http://lists.w3.org/Archives/Public/www-webdav-dasl/2003OctDec/0100.html>. |
in revision 10: No feedback from the mailing list; no change. |
| 5.19.8-opdesc-vs-contains |
change closed |
rjgodoy@fich.unl.edu.ar, 2008-02-04: ... But the optional operator DAV:contains cannot be described in these terms, because its content model is defined to be (#PCDATA) and there is no operand descriptor for #PCDATA content. ... | in revision 15: Introduce an attribute on opdesc for that; but discourage its use except for DAV:contains. |
| 5.3-select-count |
change closed |
Reference: <http://lists.w3.org/Archives/Public/www-webdav-dasl/2006JulSep/0001.html> julian.reschke@greenbytes.de, 2006-08-28: Feature request: ability just to retrieve the number of search results, see <http://lists.w3.org/Archives/Public/www-webdav-dasl/2006JulSep/0001.html> for details. |
in revision 10: No feedback from the mailing list; no change. |
| 5.4-clarify-depth |
change closed |
Reference: <http://mail-archives.apache.org/mod_mbox/jackrabbit-users/200608.mbox/%3c44EEF4C8.2010305@gmx.net%3e> marcel.reutegger@gmx.net, 2006-08-25: Are "0", "1" and "infinity" the only possible values for DAV:depth or is anything between "1" and "infinity" possible as well? |
in revision 09: Clarify by re-using text from RFC2518 (see http://lists.w3.org/Archives/Public/www-webdav-dasl/2006JulSep/0001.html). |
| 5.4.2-multiple-scope |
change closed |
Reference: <http://lists.w3.org/Archives/Public/www-webdav-dasl/2003JulSep/0012.html> prakash.yamuna@covigna.com, 2003-09-27: (asks for the ability to specify multiple scopes in a single query) julian.reschke@greenbytes.de, 2003-10-03: Consider making this an optional extension iff we can come up with a simple enough definition of it's impact on sorting/ranking and so on. Otherwise propose to reject. |
in revision 06: Allow servers to support multiple scopes in DAV:basicsearch. Make clear that this is optional. Define precondition accordingly. |
| 5.4.2-scope-vs-redirects |
change closed |
Reference: <http://lists.w3.org/Archives/Public/www-webdav-dasl/2003OctDec/0010.html> julian.reschke@greenbytes.de, 2003-10-08: Clarify the relation of scope and redirect (3xx) resources. |
in revision 10: State that the search operation doesn't follow redirects automatically. |
| 5_media_type_match |
change closed |
julian.reschke@greenbytes.de, 2003-11-30: Putting conditions on DAV:getcontenttype is hard (see <http://lists.w3.org/Archives/Public/www-webdav-dasl/2003OctDec/0101.html> is (too?) hard. Proposal for a specific operator for expressing conditions on the media type: <http://lists.w3.org/Archives/Public/www-webdav-dasl/2003OctDec/0109.html>. | in revision 10: No feedback from the mailing list; no change. |
| abnf |
change closed |
julian.reschke@greenbytes.de, 2005-02-11:
Use ABNF syntax from RFC2234.
julian.reschke@greenbytes.de, 2005-05-05: ...where applicable. That is, stick with RFC2616 grammar for HTTP definitions. |
in revision 08: Done. |
| acls |
edit closed |
julian.reschke@greenbytes.de, 2008-06-29: Clarify security considerations with respect to access rights. | in revision 16: |
| authentication |
change closed |
julian.reschke@greenbytes.de, 2006-12-16: The section "Authentication" is completely useless. Remove it. | in revision 10: Done. |
| bsschema-DTD |
change closed |
lisa@xythos.com, 2001-10-17: (1) DTD needs to be cleaned up, (2) there should be a way to advertise propdescs for all properties not mentioned otherwise. | in revision 00: |
| case-insensitivity |
change closed |
julian.reschke@greenbytes.de, 2001-10-17: I think case-insensitive comparison is underspecified here (what does it mean for generic Unicode strings?) | in revision 00: |
| case-insensitivity-name |
change closed |
julian.reschke@greenbytes.de, 2002-01-09: The attribute probably should be renamed to "caseless". | in revision 03: |
| casesensitive-no-namespace |
change closed |
julian.reschke@greenbytes.de, 2002-03-28: Technically, this attribute is NOT in the DAV: namespace (otherwise it would need to be qualified). | in revision 01: |
| cleanup-iana |
change closed |
julian.reschke@greenbytes.de, 2006-12-16: Cleanup the IANA considerations. Add HTTP header registration for DASL header. | in revision 10: Done. |
| datatypes |
change closed |
julian.reschke@greenbytes.de, 2001-10-17: Should use standard datatypes from XML Schema Part 2 and also allow for user-defined types. | in revision 00: |
| DB2/DB7 |
change closed |
Reference: <http://lists.w3.org/Archives/Public/www-webdav-dasl/1999OctDec/0023.html> ejw@ics.uci.edu, 2000-04-20: Dates (HTTPDate in getlastmodified). ejw@ics.uci.edu, 2000-04-20: Agreement that it is OK to submit isodate to search HTTPDate (i.e., it's a marshalling issue only). ejw@ics.uci.edu, 2000-04-20: Booleans appear to be underspecified in the specification. How is a boolean tested, and what are the behavior of operators like less than, greater than, etc. julian.reschke@greenbytes.de, 2002-01-28: I think similar questions apply to booleans. Proposal: allow specification of the literal's type using XML Schema simple types, and declare that "both" WebDAV date types are compatible. ABabich@filenet.com, 2002-01-29: The current DASL draft doesn't really have Booleans or any other data type. It's trying to skate on data types. Booleans could be tested using the "eq" and the combination "not eq", if you had well defined literals for TRUE and FALSE. With the current syntax, that is the way you would have to test a Boolean. Generally, Boolean values are not considered to be ordered, so "gt" etc. wouldn't apply. However, if the literal values of a Boolean were 1 and 0 for TRUE and FALSE (using the most commonly used convention of positive logic), then you would have an obvious ordering. 1 and 0 have the advantage of being language independent. You now see a lot of electronic and electro-mechanical devices (air conditioners, computers, etc.) with a "1/0" label on the power switch, "1" meaning "on", and "0" meaning "off". SQL databases don't have Booleans. SQL doesn't control DASL, of course, but SQL databases are so widely used that they are important. The closest thing in SQL is a bit field. Each bit in a bit field is zero or 1. So, why not close the issue by saying: DASL doesn't have data types. You can simulate Booleans by an integer data type, using 1 for "TRUE" and 0 for "FALSE". julian.reschke@greenbytes.de, 2002-10-22: let's consider a dead property "foo", and some resources a, b and c on which this dead property is defined and has the values "1", "3" and "10". Consider a DAV:basicsearch with the where clause: <gte xmlns="DAV:"> <prop><foo xmlns=""/></prop> <literal>3</literal> </gte> Which resource will match? As DAV:basicsearch currently isn't type-aware, the server will have to do a string comparison, and only the b (with value "3") will match. Is this really sufficient? It basically means that dead property comparisons are restricted to strings. Proposals: a) If the server happens to have type information for a dead property, it should try to do a comparison according to the known property type, if the literal can be parsed into this type. This basically replicates the behaviour that a client would expect when querying on live properties such as DAV:getcontentlength, so it could be taken as a simple clarification. Extended proposal: b) A client can enforce comparison using a specific data type by specifying the type in the query, for instance using: <gte xmlns="DAV:"> <prop><foo xmlns=""/></prop> <literal xsi:type="xs:long">3</literal> </gte> Martin.Wallmer@softwareag.com, 2002-11-25: What about existing implementations? Currently a server might react with "xsi:type unknown entity" or just ignore it (which would mean: String comparison) julian.reschke@greenbytes.de, 2002-11-25: OK, how about *adding* an alternative to DAV:literal? Therefore: DAV:literal: untyped, server can compare according to it's internal knowledge of types (with the clarification above) DAV:typed-literal: typed according to the xsi:type attribute -- "new" servers can implement this without affecting any existing code. We'll need to think about discovery of this feature, though. It might be possible to do this with QSD (in the meantime, are there any QSD implementations except ours?) |
in revision 05: WG meeting feedback: define DAV:typed-literal. Also allow DAV:literal to be evaluated by the server according "internal" type knowledge. Require timestamps to be ISO, even for DAV:getlastmodified. |
| DB3 |
change closed |
Reference: <http://lists.w3.org/Archives/Public/www-webdav-dasl/1999OctDec/0023.html> ejw@ics.uci.edu, 2000-04-20: What should the default Depth value be for SEARCH? ejw@ics.uci.edu, 2000-04-20: Agreement that Depth must be sent with SEARCH. |
in revision 00: |
| DB7 |
change closed |
Reference: <http://lists.w3.org/Archives/Public/www-webdav-dasl/1999OctDec/0023.html> ejw@ics.uci.edu, 2000-04-20: Searches on XML chunks that include namespaces. Need to expand out the XML namespace when doing the search (i.e., do search on DAV:foo, not X:foo xmlns:X="DAV:") Also an issue for expressing searches on XML sub-elements of properties. julian.reschke@greenbytes.de, 2002-01-28: I think this is out-of-scope for now. |
in revision 00: |
| dtd |
edit closed |
julian.reschke@greenbytes.de, 2008-02-11: Fix various bugs in DTD fragments. | in revision 15: Done. |
| duplicate-invalid-scope |
change closed |
Reference: <http://lists.w3.org/Archives/Public/www-webdav-dasl/2003JanMar/0001.html> julian.reschke@greenbytes.de, 2003-01-09: This is in conflict with section 2.6. Proposal: remove this part. |
in revision 03: |
| encoding |
edit closed |
julian.reschke@greenbytes.de, 2002-02-18: Make sure that all examples specify an encoding when content type text/xml is used. | in revision 00: |
| introduction |
change closed |
julian.reschke@greenbytes.de, 2002-01-25: Need to rewrite introduction stating that is based on the expired WebDAV DASL internet draft. | in revision 00: |
| invalid-scope |
change closed |
julian.reschke@greenbytes.de, 2003-01-09:
Marshalling a BAD REQUEST with an (extended) multistatus body seems to
be a weird approach. Should be resolved by finally adopting the RFC3253
error marshalling.
julian.reschke@greenbytes.de, 2003-01-28: Funny enough, Roy Fielding's feedback on a related issue indicates that this may be the absolutely right thing to do. Needs coordination with RFC2518bis activity. |
in revision 05: Document style change to use RFC3253 preconditions. |
| is-collection |
change closed |
julian.reschke@greenbytes.de, 2002-01-09: Update DTD and move up to the other operators. | in revision 00: |
| iscollection-operator |
change closed |
julian.reschke@greenbytes.de, 2001-10-09: DAV:iscollection should be an operator rather than a pseudo-property. This both reduces special cases in implementations and avoids confusion with real properties. | in revision 00: |
| isdefined-optional |
change closed |
Reference: <http://lists.w3.org/Archives/Public/www-webdav-dasl/2002AprJun/0042.html> julian.reschke@greenbytes.de, 2002-06-25: It's unclear why isdefined is an optional parameter. |
in revision 02: |
| JW12 |
change closed |
Reference: <http://lists.w3.org/Archives/Public/www-webdav-dasl/1999OctDec/0023.html> ejw@ics.uci.edu, 2000-04-20: Allowing relative URIs isn't very useful. ejw@ics.uci.edu, 2000-04-24: Accepted 24 April 2000. julian.reschke@greenbytes.de, 2002-02-18: Need agreement on either forbidding relate URIs or leaving them in (which doesn't seem to be hard to implement). julian.reschke@greenbytes.de, 2002-03-03: Relative URI reference resolving code is required in WebDAV anyway, so the issue is closed. |
in revision 00: |
| JW13 |
edit closed |
Reference: <http://lists.w3.org/Archives/Public/www-webdav-dasl/1999AprJun/0002.html> ejw@ics.uci.edu, 1999-04-26: Section 5.6 should have a separate section, with a separate heading, for the description of ascending and descending. I had a hard time finding these descriptions without this section heading. julian.reschke@greenbytes.de, 2002-03-03: Added to index. |
in revision 00: |
| JW14 |
change closed |
Reference: <http://lists.w3.org/Archives/Public/www-webdav-dasl/1999AprJun/0002.html> ejw@ics.uci.edu, 2000-04-20: How does xml:space affect DAV:literal. julian.reschke@greenbytes.de, 2002-01-28: Do we just need an example here? julian.reschke@greenbytes.de, 2002-03-01: Re-opened: see discussion in DASL mailing list: using xml:space would be inconsistent with WebDAV. |
in revision 00: |
| JW14b |
change closed |
Reference: <http://lists.w3.org/Archives/Public/www-webdav-dasl/1999AprJun/0002.html> ejw@ics.uci.edu, 2000-04-20: The semantics of DAV:literal should not change inside a DAV:like. julian.reschke@greenbytes.de, 2002-01-28: Does it? Need details. julian.reschke@greenbytes.de, 2002-03-03: Closed; I think this is clear from the spec. |
in revision 00: |
| JW15 |
change closed |
Reference: <http://lists.w3.org/Archives/Public/www-webdav-dasl/1999AprJun/0002.html> ejw@ics.uci.edu, 1999-04-26: The BNF for a wildcard permits the entry of "</d:literal>" which would confuse parsers. Also, the BNF sequence for text should use characters instead of octets, to better handle multi-octet character set representations (like UTF-16). julian.reschke@greenbytes.de, 2002-03-03: Non-issue: the contents of the DAV:literal element is subject to normal XML escaping. Grammar changed to use chars rather than octets. |
in revision 00: |
| JW16b/JW24a |
change closed |
Reference: <http://lists.w3.org/Archives/Public/www-webdav-dasl/1999AprJun/0002.html> ejw@ics.uci.edu, 2000-04-20: Define how comparisons on strings work, esp for i18n. Need policy statement about sort order in various national languages. (JW said "non-Latin" but it's an issue even in languages that use the latin char set.) julian.reschke@greenbytes.de, 2003-01-28: This issue not only applies to the comparison operators, but also to ordering! |
in revision 10: Related to issue language-comparison. Close this one. |
| JW17/JW24b |
change closed |
Reference: <http://lists.w3.org/Archives/Public/www-webdav-dasl/1999AprJun/0002.html> ejw@ics.uci.edu, 2000-04-20: 5.13 should discuss handling of queries when character set differs. Some text on handling character sets would be helpful. julian.reschke@greenbytes.de, 2003-01-10: There's not a lot we can say -- the charset for the query is irrelevant due to XML, and charsets in the resources to be searched are treated seems to be very server-specific. As the semantics for DAV:contains are intentionally very flexible, I think we shouldn't say anything about this topic. |
in revision 03: |
| JW24c |
change closed |
Reference: <http://lists.w3.org/Archives/Public/www-webdav-dasl/1999AprJun/0002.html> ejw@ics.uci.edu, 2000-04-20: How do string equality and language tag interact. Cross-language comparison should work at least when the two languages are dialects, e.g. en-us vs en-uk. julian.reschke@greenbytes.de, 2002-01-28: Proposal: strings match if and only if they match character by character. julian.reschke@greenbytes.de, 2003-01-09: Note that XPath 2.0 currently defines no collation-aware equality operator, so I think we should just follow that example. Note that this basically is a duplicate of issue JW16b/JW24a. julian.reschke@greenbytes.de, 2003-01-28: They don't interact. See separate issue on putting conditions on the xml:lang attribute. |
in revision 03: |
| JW24d |
edit closed |
Reference: <http://lists.w3.org/Archives/Public/www-webdav-dasl/1999AprJun/0002.html> ejw@ics.uci.edu, 2000-04-20: Where does xml:lang go in a query? julian.reschke@greenbytes.de, 2002-02-28: What would be the *purpose* of putting xml:lang into a query? jrd3@alum.mit.edu, 2002-05-28: The purpose is to allow one to express queries more precisely, e.g. to distinguish between the English word "hoop" (a circular object) and Dutch "hoop" (hope). Imagine a property that holds keywords for a resource. See 4.4 in http://www.ietf.org/rfc/rfc2518.txt, and 2.12 in http://www.w3.org/TR/REC-xml julian.reschke@greenbytes.de, 2002-05-28: I think this would be an interesting feature, but it seems to be extremely hard to implement. So assuming a query that - the query specifies a language and - be the text content of the property matches The result will be: 1) true (match), if the property was stored with a matching xml:lang property (where the language tag matching rules would have to apply) 2) undefined if the property was stored without xml:lang 3) false otherwise On the other hand if - the query doesn't specify a language the result will be: 4) undefined (at least according to the current wording). So, 1) requires that the query engine actually knows how to match language tags -- I'm not sure that everybody is willing to implement that. 2) is this desirable? 3) ok. 4) that seems to be wrong. If the query doesn't care, it should match, right? Other problems: - what is the language of a date-typed property? - (sic!) where should xml:lang go into the query? There's no XML feature to undefine an xml:lang which is in scope, but there may be cases where this is needed. On the other hand, if we drop this requirement, a client can still do a query and then process the result set -- the property elements in the response body will be reported with xml:lang (when persisted with language) anyway. So I'd recommend to drop the feature. Defining string comparisons vs. collation sequences is hard enough. julian.reschke@greenbytes.de, 2003-01-09: (Proposal to reject) julian.reschke@greenbytes.de, 2003-01-28: WG meeting feedback: should be moved into explicit operators (see proposal on mailing list). Open: is this optional or required? |
in revision 05: Add new optional operators. |
| JW25/JW26 |
edit closed |
Reference: <http://lists.w3.org/Archives/Public/www-webdav-dasl/1999AprJun/0002.html> ejw@ics.uci.edu, 2000-04-20: In Security Considerations, copy XML considerations from webDAV spec. ejw@ics.uci.edu, 2000-04-20: Wouldn't it be better to just cite the XML document, so that if that document is updated, we won't have stale information? ejw@ics.uci.edu, 2000-04-20: In Security Considerations, mention privacy risks of queries. julian.reschke@greenbytes.de, 2002-01-28: Is this resolved? julian.reschke@greenbytes.de, 2003-01-09: Closed. Havn't heard of missing considerations. |
in revision 03: |
| JW3 |
change closed |
Reference: <http://lists.w3.org/Archives/Public/www-webdav-dasl/1999AprJun/0002.html> ejw@ics.uci.edu, 1999-04-26: This specification essentially defines a new type of Web resource, of type "search arbiter". This raises a number of questions regarding how this kind of resource interacts with existing HTTP methods. I would expect to see a section which goes through and details the interactions between HTTP and WebDAV methods and search arbiters. For example, it seems reasonable to me to allow a search arbiter to potentially reply to GET (perhaps with a human-meaningful description of the capabilities of the arbiter), and for this GET response to potentially be authorable using PUT, and locked using LOCK. However, I wouldn't expect COPY, MOVE, or DELETE to work, although I would expect PROPPATCH and PROPFIND to work OK. Another issue is what kind of resource type a search arbiter returns in the resourcetype property (I'd expect a <searcharbiter/> element). ejw@ics.uci.edu, 1999-04-26: How does a search arbiter respond to searches, if the search arbiter URI is within a search scope? The answer to this is related to the answer to whether a search arbiter has its own properties, body, etc. julian.reschke@greenbytes.de, 2002-03-03: A SEARCH arbiter is no special kind of resource and thus this spec doesn't define any particular behaviour. Martin.Wallmer@softwareag.com, 2002-03-08: for my understanding the term "search arbiter" is an abstract term for a piece of software, that suplies the SEARCH funcionality. As DASL is an extension of WEBDAV, this piece of software will always be a complete WebDAV server with the well defined behavior of GET, PROPFIND and so on. So no additional definition is necessesary IMHO. |
in revision 00: |
| JW4/DB4/DB5 |
change closed |
Reference: <http://lists.w3.org/Archives/Public/www-webdav-dasl/1999AprJun/0002.html> ejw@ics.uci.edu, 1999-04-26: Section 2.5 states that the 507 (Insufficient Storage) status code should be returned when SEARCH produces more responses that the server is willing to immediately return. A 5xx status code isn't appropriate for this case, since the response does have valid search results, indicating that the client correctly submitted a search, and this search was successfully performed by the server, even if it isn't returning all search results. I recommend defining a new status code for this case, 208 (Partial Results). ejw@ics.uci.edu, 2000-04-20: When results are truncated, server replies with a 507 and also returns an XML element. ejw@ics.uci.edu, 2000-04-20: 507 is currently in conflict with other specs. Need to avoid collisions. julian.reschke@greenbytes.de, 2002-02-18: Use 207 (Multistatus) instead. |
in revision 00: |
| JW5 |
change closed |
Reference: <http://lists.w3.org/Archives/Public/www-webdav-dasl/1999AprJun/0002.html> ejw@ics.uci.edu, 1999-04-26: On the topic of partial search results, DASL currently has no way for a client to request the next chunk of a set of search results. Since *every* search service I've interacted with on the Internet has a feature for returning the next set of search results, I really would expect this feature to be in DASL. An explanation for why this feature isn't present should be in the protocol specification if it is not going to be supported. Martin.Wallmer@softwareag.com, 2002-03-08: of course this issue is legitim. However, as basicsearch should be as simple as possible, I tend to say out of scope as well. But perhaps this could be an optional feature (is it that, what you mean by extension to DAV:basicsearch)? julian.reschke@greenbytes.de, 2002-03-08: Moved into DAV:basicsearch section, because this is a request for a specific query grammar feature. julian.reschke@greenbytes.de, 2003-01-09: Closed because of lacking feedback. |
in revision 03: |
| JW8 |
change closed |
Reference: <http://lists.w3.org/Archives/Public/www-webdav-dasl/1999AprJun/0002.html> ejw@ics.uci.edu, 2000-04-20: Is the response from SEARCH cacheable? (No). |
in revision 00: |
| JW9 |
change closed |
Reference: <http://lists.w3.org/Archives/Public/www-webdav-dasl/1999AprJun/0002.html> ejw@ics.uci.edu, 1999-04-26: How does a DAV client discover which search arbiter can be used to search a portion of the DAV namespace? At present, the specification seems to imply two things (a) that "/" might be a typical arbiter, and (b) that other arbiters can exist and you can get redirected to them. If this issue isn't addressed in the specification, it might lead to clients having hard-coded search arbiter locations, thus forcing servers to put an arbiter at those locations or be non-interoperable. Or, it will require clients to be configured with the search arbiter location, which also seems bad. It seems far better to have a predefined mechanism which clients can use to discover the location of the search arbiter. One simple mechanism would be to define a property on each collection (but not each resource) which gives the location(s) of appropriate arbiters. julian.reschke, 2002-03-10: If a WebDAV-enabled collection is smart enough to know about search arbiters in scope, couldn't it be just forward SEARCH requests to those (making itself a kind of proxy arbiter?). Issue closed as this doesn't seem to solve the *general* discovery problem. |
in revision 00: |
| language-comparison |
change closed |
Reference: <http://lists.w3.org/Archives/Public/www-webdav-dasl/2002JanMar/0122.html> julian.reschke@greenbytes.de, 2002-03-03: XPath/XQuery (see draft, and open issue) specify string comparisons based on collations, not languages. I think we should adopt this. This would mean that "xml:lang" would be removed, and an optional attribute specifying the name of the collation is added. julian.reschke@greenbytes.de, 2003-01-09: Proposal: adopt "lang" and "collation" attribute from XSLT 2.0's xsl:sort. |
in revision 10: Won't fix: no indication that implementors currently want this feature, or would be able to implement it. |
| like-exactlyone |
change closed |
Reference: <http://lists.w3.org/Archives/Public/www-webdav-dasl/2002OctDec/0012.html> julian.reschke@greenbytes.de, 2002-11-27: SQL actually uses "_" for "exactlyone". julian.reschke@greenbytes.de, 2002-11-28: Replaced the character, also fixed the "character" production ("( exactlyone | zeroormore | escapechar )" are not valid characters here, because they need to be escaped). |
in revision 03: |
| like-wildcard-adjacent |
change closed |
Reference: <http://lists.w3.org/Archives/Public/www-webdav-dasl/2002OctDec/0014.html> julian.reschke@greenbytes.de, 2002-11-27: This seems to imply that "__" (to match any two-character sequence) is not allowed. Does anybody remember why one would want that? julian.reschke@greenbytes.de, 2002-12-14: Another thing I'd like to see clarified: Is it allowed to use "\" to escape characters other than "\", "%" and "_"? What does ANSI SQL say about this? julian.reschke@greenbytes.de, 2003-01-29: Feedback from Fred Zemke (Oracle): 1) I just looked in the SQL standard and did not see anything prohibiting two consecutive underscores as a pattern. If anyone disagrees, please tell me the basis for your disagreement. My basis is SQL:1999 Foundation 8.5 <like predicate> GR 3)b)i)2). 2) The standard does not permit the escape character to be used in a LIKE predicate patterm, except immediately before another escape character, the underscore or the percent sign. An implementation is supposed to raise an exception otherwise. [SQL:1999 Foundation 8.5 <like predicate> GR 3)b)i)2) ]. However, I believe it is a common vendor practice to permit the escape character to precede any character. Such an implementation is, strictly speaking, nonconforming, though users seldom complain if a vendor finds a way to process a statement without raising an exception. |
in revision 03: |
| limit-vs-ordering |
edit closed |
Reference: <http://lists.w3.org/Archives/Public/www-webdav-dasl/2002OctDec/0033.html> julian.reschke@greenbytes.de, 2003-02-07: The spec as written does not define any interaction between DAV:nresults and DAV:score, so if you'd ask for 10 results, sorted by score, you still couldn't rely on the 10 results being reported actually *being* the top 10 results. Of course that's what people probably would expect, so it seems we need to fix this (the interaction of limiting the result set and sorting the results) anyway. |
in revision 03: |
| mixed-content-properties |
change closed |
Reference: <http://lists.w3.org/Archives/Public/www-webdav-dasl/2002OctDec/0020.html> julian.reschke@greenbytes.de, 2002-11-27: Does this mean "undefined" as (1) "not defined by this specification" or (2) as in SQL's three-valued logic? For the sake of interoperability, I'd vote for (2). If an implementation wants to support matching in mixed/element content, it will then have to *explicitly* extend DAV:basicsearch. |
in revision 03: |
| namespace |
change closed |
julian.reschke@greenbytes.de, 2002-01-25: As this is an individual (non working group) submission, it should not use the DAV: namespace for any new elements. Need to collect feedback. | in revision 00: |
| naming-of-elements |
change closed |
julian.reschke@greenbytes.de, 2001-10-17: To stay consistent with other WebDav specs, I'd prefer to use "-" instead of "_" as separator. | in revision 00: |
| null-ordering |
edit closed |
Reference: <http://lists.w3.org/Archives/Public/www-webdav-dasl/2002JanMar/0101.html> ameliac@us.ibm.com, 2002-02-20: In the WebDAV SEARCH spec (5.6, DAV:orderby), it says that nulls sort low, to match SQL92. However, SQL92 and SQL99 both say "Whether a sort key value that is null is considered greater or less than a non-null value is implementation-defined, but all sort key values that are null shall either be considered greater than all non-null values or be considered less than all non-null values." (words taken from SQL99, 14.1 <declare cursor> General Rule 2)c), in reference to null handling for the <order by clause>. ) I would note that in 5.5.3 WebDAV SEARCH says nulls are less than all other values in a comparison, so the DAV:orderby matches that statement, it just gives an inaccurate reason. julian.reschke@greenbytes.de, 2003-01-09: Seems to me that if SQL databases are free to decide where to sort NULL values (as long as they are consistent), we probably need to be just as flexible in DASL (otherwise we can't directly map to a SQL query). ABabich@filenet.com, 2003-01-09: (1) Amelia is completely correct. (2) We MUST specify a definite ordering for nulls in the collation sequence if we ever hope to extend DASL in the future to cross-repository queries that do ordering. (Trust me, customers really want that.) Despite the fact that the SQL spec. caved in to one or more vendors who didn't want to change their implementation of where nulls sort, there is only one logical choice as to where null values sort -- before all non-null values. That is because shorter strings always collate before longer strings, and zero length strings are the shortest strings of all. That is the way the DASL spec. is written. (3) The only imperfection in the spec is that, as Amelia says, the reason is inaccurate. So, to correct the imperfection, you might say something like the following: "Nulls sort low, i.e., before all non null values. That is compatible with the SQL92 and SQL99 specs., and it is essential for a future extension for cross-repository searching." Or, you could just say "That is compatible with the SQL92 and SQL99 specs." for the reason. |
in revision 03: |
| order-precedence |
edit closed |
Reference: <http://lists.w3.org/Archives/Public/www-webdav-dasl/2003JanMar/0020.html> julian.reschke@greenbytes.de, 2003-01-14: This example seems to contradict section 5.6: "Comparisons are applied in the order they occur in the DAV:orderby element, earlier comparisons being more significant." |
in revision 03: |
| ordering-vs-limiting |
change closed |
jbarone@xythos.com, 2008-08-04: I read this to mean that the full results should first be ordered by the server, and then send back the requested limit. This seems to contradict what's specified in section 2.3.1, where the results are limited and then ordered (if I'm reading it correctly). I think these 2 sections should be consistent with each other. | in revision 18: Relax requirement to SHOULD. |
| qsd-optional |
change closed |
julian.reschke@greenbytes.de, 2003-01-28:
WG January meeting feedback: QSD should be made required.
kwiggen@xythos.com, 2003-10-03: (significant pushback, see mailing list thread at http://lists.w3.org/Archives/Public/www-webdav-dasl/2003OctDec/0003.html). |
in revision 10: Leave it optional. |
| qsd-pseudo-property |
closed |
julian.reschke@greenbytes.de, 2002-01-25:
It would be nice to avoid the definition of a "pseudo" property just for this special use case.
julian.reschke@greenbytes.de, 2002-06-10: Proposal for alternate format at: (mailing list) |
in revision 01: |
| qsd-req-validity |
change closed |
julian.reschke@greenbytes.de, 2007-11-09: Raised by Javier Godoy in private email: the XML child element below DAV:query-schema-discovery does not need to be a valid query; and the example in 4.1.1 shows that. | in revision 14: Apply minimal fix to DTD comment. |
| query-on-href |
change closed |
Reference: <http://lists.w3.org/Archives/Public/www-webdav-dasl/2002JanMar/0108.html> julian.reschke@greenbytes.de, 2002-02-28: DAV:href isn't a property, so it can't be used in queries. Is this a problem? Examples where DAV:displayname is queried instead seem to indicate that. A possible solution would be to allow DAV:href whereever DAV:prop is allowed in the where clause. julian.reschke@greenbytes.de, 2002-11-27: Closed (nobody seems to care). |
in revision 03: |
| querygrammar-prop |
change closed |
julian.reschke@greenbytes.de, 2001-10-09: DAV:queryschema was selected, but DAV:querygrammar was returned. | in revision 00: |
| queryschema-prop |
change closed |
julian.reschke@greenbytes.de, 2001-10-09: DAV:queryschema does not appear in a DAV:prop. Intentional? | in revision 00: |
| response-format |
edit closed |
julian.reschke@greenbytes.de, 2007-01-28: Use proper RFC2518 compliant DAV:response elements. | in revision 11: Done. |
| result-truncation |
change closed |
Reference: <http://lists.w3.org/Archives/Public/www-webdav-dasl/2002JanMar/0163.html> ldusseault@xythos.com, 2002-03-29: I believe the same response body that contains the first N <DAV:response> elements should also contain a *different* element stating that the results were incomplete and the result set was truncated by the server. There may also be a need to report that the results were incomplete and the result set was truncated at the choice of the client (isn't there a limit set in the client request?) That's important so the client knows the difference between receiving 10 results because there were >10 but only 10 were asked for, and receiving 10 results because there were only exactly 10 results and it just happens that 10 were asked for. jrd3@alum.mit.edu, 2002-05-28: I agree that this could be useful, but I think this issue should be consolidated with issue JW5 (see below), which proposes that DASL basicsearch ought to have a way for client to request additional result sets. It should be moved because there is little or no value in allowing a client to distinguish between the case where "N results were requested, and there are exactly N available" and "N results were requested, and there are more than N available" if there is no way for client to get the next batch of results. julian.reschke@greenbytes.de, 2003-01-28: Feedback from interim WG meeting: agreement that marshalling should be rewritten and backwards compatibility is not important. Proposal: extend DAV:multistatus by a new child element that indicates (1) the range that was returned, (2) the total number of results and (3) a URI identifying the result (for resubmission when getting the "next" results). Such as
<multistatus xmlns='DAV:'>
<search-result>
<href>...identifier for result set...</href>
<total><-- number of results --></total>
<start><-- 1-based index of 1st result --></start>
<length><-- size of result set returned --></length>
<partial-result/><-- indicates that this is a partial result -->
</search-result>
...response elements for search results...
</multistatus>
The example below would then translate to:
HTTP/1.1 207 Multistatus
Content-Type: text/xml; charset="utf-8"
Content-Length: xxx
<?xml version="1.0" encoding="utf-8"?>
<D:multistatus xmlns:D="DAV:">
<D:search-result>
<D:partial-result/>
</D:search-result>
<D:response>
<D:href>http://www.example.net/sounds/unbrokenchain.au</D:href>
<D:propstat>
<D:prop/>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
<D:response>
<D:href>http://tech.mit.test/archive96/photos/Lesh1.jpg</D:href>
<D:propstat>
<D:prop/>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>
Q: do we need all elements, in particular start and length?
julian.reschke@greenbytes.de, 2003-10-07: Related: if this is supposed to be normative to DAV:basicsearch, it can't stay in an "example" sub-section. |
in revision 11: Move the explanation of Result Set Truncation into a normative section, and just leave the actual example in the "Example" subsection. Leave the reminder as-is, and not the missing result paging feature in an appendix. |
| results-vs-binds |
edit closed |
Reference: <http://lists.w3.org/Archives/Public/www-webdav-dasl/2002AprJun/0047.html> julian.reschke@greenbytes.de, 2002-06-26: Given a URL space which supports the binding protocol, and which actually contains multiple binds for a resource matching the search conditions. What do we expect: 1) only one of the URIs is reported, 2) all of them are reported. Case 1) may be better for simple clients that aren't aware of the existence of BIND. Case 2) may be required for more advanced clients (that actually *want* to find all bindings, and can select DAV:resourceid to decide which of the reported URIs map to the same resource). |
in revision 03: |
| rfc2606-compliance |
edit closed |
julian.reschke@greenbytes.de, 2007-01-28: Make sure domain names in examples use the names allowed bc RFC2606. | in revision 11: Done. |
| rfc4918 |
edit closed |
julian.reschke@greenbytes.de, 2007-06-30: Update RFC2518bis reference to RFC4918. | in revision 13: Done. |
| safeness |
edit closed |
Reference: <http://www.w3.org/mid/4894155E.2000807@gmx.de> julian.reschke@greenbytes.de, 2008-08-02: State that the SEARCH method is safe. |
in revision 18: Done. |
| scope-collection |
change closed |
Reference: <http://lists.w3.org/Archives/Public/www-webdav-dasl/1998JulSep/0021.html> jrd3@alum.mit.edu, 1998-07-07: In earlier email, I proposed that scope should be broadened to be any kind of URI, not just URLs of WebDAV collections. If we can't do that, can I suggest that we at least broaden the definition of scope to be any kind of resource, not just collection resources? |
in revision 02: |
| scope-discovery |
change closed |
julian.reschke@greenbytes.de, 2008-07-02: State that there's no way to discover supported scopes, but also add a SHOULD requirement for a scope to be supported by DAV:basicsearch. | in revision 16: |
| scope-vs-versions |
change closed |
Reference: <http://lists.w3.org/Archives/Public/www-webdav-dasl/2002AprJun/0047.html> julian.reschke@greenbytes.de, 2003-02-05: A relatively frequent use case for servers that both support versioning and DASL seems to have searches that include all versions of the resources in scope. In general, the version URIs may not be in the scope of the query. Therefore, I'd like to extend the DAV:scope to specify inclusion of versions. This would be an optional extension -- however, a server that does not support his feature should reject the request (so that the client would know that the request could not be satisfied). Example:
<d:from xmlns:d="DAV:">
<d:scope>
<d:href>/container1/</d:href>
<d:depth>infinity</d:depth>
<d:include-versions />
</d:scope>
</d:from>
Martin.Wallmer@softwareag.com, 2003-02-06: just to clarify: 1. If a resource in scope has versions, the server SHOULD take care of versions as well. 2. If the client specifies <d:include-versions />, the server MUST take care of versions or MUST reject the request. 3. If the user does not want to get versions, he must specify <not xmlns="DAV:"><is-defined><version-name /></is-defined></not> ... Is my understanding correct? However, a defined "switch" (include - exclude) could be a good hint for the server in terms of performance, so I'd prefer a <d:exclude-versions/> as well. Alternatively the server should only include the versions, if <d:include-versions /> is specified. Does this make sense? julian.reschke@greenbytes.de, 2003-02-06: I don't like that, because I'd prefer to keep the definition of "scope" intact. If versions happen to be in the namespace scope, they should be in scope of the search as well. Thus the proposal to add a specific element that *extends* the scope of the query. |
in revision 05: Add proposed feature. |
| score-pseudo-property |
change closed |
julian.reschke@greenbytes.de, 2002-02-28:
Shouldn't be done using a pseudo-property. Report
it as child of DAV:propstat instead?
julian.reschke@greenbytes.de, 2002-11-27: Proposal: - remove language about it being a pseudo-property (no need to DAV:select it, do not support ordering on it) - marshall it as child element of DAV:response within the search result (say that it SHOULD be added if the query involved DAV:contains) |
in revision 03: |
| select-allprop |
change closed |
Reference: <http://lists.w3.org/Archives/Public/www-webdav-dasl/2002JulSep/0011.html> Martin.Wallmer@softwareag.com, 2002-08-12: Should a DAV:allprop SEARCH on a Delta-V enabled resource return all Delta-V properties as well? |
in revision 02: |
| standardstrack |
change closed |
julian.reschke@greenbytes.de, 2008-06-27: Umbrella issue for changes making this a candidate for the Standards Track. | in revision 17: |
| typed-literal |
change closed |
julian.reschke@greenbytes.de, 2003-01-15:
1. (insert language defining the comparison following the rules defined in
http://www.w3.org/TR/xpath20/#id-comparisons).
2. Extend Basicsearch QSD grammar to support discovery of typed-literal 3. Update DTD. 4. Discuss behaviour of DAV:literal when the property's type is known for the complete search scope (is the server allowed to be "smart"?) julian.reschke@greenbytes.de, 2003-10-11: 3.: done julian.reschke@greenbytes.de, 2006-03-16: 2.: done julian.reschke@greenbytes.de, 2007-01-24: 1.: done (note that the relevant section is in XPATHFUNC). julian.reschke@greenbytes.de, 2007-01-24: 4.: this was already stated for DAV:literal since draft 03. |
in revision 10: Done. |
| undefined-expressions |
edit closed |
Reference: <http://lists.w3.org/Archives/Public/www-webdav-dasl/2002OctDec/0001.html> julian.reschke@greenbytes.de, 2002-10-22: WebDAV properties do not have "null" values. |
in revision 02: |
| undefined-properties |
change closed |
Reference: <http://lists.w3.org/Archives/Public/www-webdav-dasl/2002OctDec/0021.html> julian.reschke@greenbytes.de, 2002-11-27: Shouldn't this say: "If a PROPFIND for a property value would yield any non-200 (OK) response for that property, then that property is considered NULL."? |
in revision 03: |
| update-webdav |
edit closed |
julian.reschke@greenbytes.de, 2007-03-10: Update reference from RFC2518 to draft-ietf-webdav-rfc2518bis. | in revision 12: |
| URI-vs-QNAME |
change closed |
julian.reschke@greenbytes.de, 2001-10-17: Here, a grammar is represented as an URI. Later, a grammar is identified by a Qualified XML name (URI reference + local name). This means that the client needs to be aware of a mapping from a URI (that's reported here) to an XML element name (that it can use in a query). Proposal: report XML-based grammars through a different mechanism in SEARCH (details to be done). | in revision 00: |
| URIs |
change closed |
Reference: <http://lists.w3.org/Archives/Public/www-webdav-dasl/2002JanMar/0124.html> julian.reschke@greenbytes.de, 2002-03-03: Need to cleanup draft to use correct terms for URIs and URI references. |
in revision 00: |
| Version | Issues |
|---|---|
| latest | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| |
| 18 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| |
| 17 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| |
| 16 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| |
| 15 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| |
| 14 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| |
| 13 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| |
| 12 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| |
| 11 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| |
| 10 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| |
| 09 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| |
| 08 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| |
| 07 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| |
| 06 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| |
| 05 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| |
| 04 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||| |
| 03 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||| |
| 02 | |||||||||||||||||||||||||||||||||||||||||||| |
| 01 | |||||||||||||||||||||||||||||||||||||||| |
| 00 | ||||||||||||||||||||||||||||||||||||| |
Last change: 2008-10-10