- From: Clemm, Geoff <gclemm@rational.com>
- Date: Thu, 11 Jul 2002 08:51:33 -0400
- To: "'Webdav WG (E-mail)'" <w3c-dist-auth@w3c.org>
From: Larry Masinter [mailto:LMM@acm.org] What about the usage of the terms URI, URL and URN do you actually need? In what way does the definition of these terms affect the WebDAV specification? Most of the terminology is really just advisory. I also don't see what changes we need/expect from RFC-2396. The language there is quite clear. The superclass is "URI". The subclass of "locatable" URIs (i.e. ones that you can type in to a client and expect it to "locate" the specified resource is "URL". The subclass of "naming" URIs (ones that will never be shared by two "different" resources) is URN. In WebDAV, we have some URIs that we SHOULD/MUST be usable to locate the resource. We should call those "URLs" to emphasize that point. For example, the contents of the DAV:href elements returned in DAV:response should be URLs (or more accurately, URL-references). We also have some URIs which name a resource (in particular, lock tokens). These should be called URNs. And while I'm responding to this thread anyway, a few comments on one of Julian's messages: From: Julian Reschke [mailto:julian.reschke@gmx.de] Some more comments inline. > - Change to refer to URL whenever we refer to the address of a > collection or resource. This replaces the definition of "Member > URI" with "Member URL" in the Terminology section, and replaces > URI with URL in the definition of that. Same with "Internal > Member URI" to "Internal Member URL". Many other instances of > URI will be replaced with URL according to this new terminology > approach. E.g. throughout sections 5.2, 5.4, 7.5, 8.1, and > 8.10.3 . When 5.4 refers to source URIs, it needs to continue to do so. Source resources may not be HTTP resources at all. Whether or not it is an HTTP URI/URL is not the issue here. I believe that the purpose of the source property is to locate the resource, and therefore I believe it is appropriately called a URL. 8.1: "Each response XML element MUST contain an href XML element that gives the URI of the resource on which the properties in the prop XML element are defined" needs to be fixed in that the DAV:href element must be defined to be a "URI reference to be resolved relative to the request URI" I agree. 8.10.3: don't agree - resources may have alternate URIs which do not happen to be URLs. I disagree. This is about URIs at which the resource is "available". To me, being available means it is a URL, i.e. can be used to locate the resource. > - Continue to refer to URI when discussing lock > tokens. E.g. section 6.3, 6.4 I disagree with this comment (note that this was something in the original message, not something from Julian's post). We should use the term URN when discussing lock tokens. > - Continue to define the property name as a URI in section 16. As mentioned before, properties do not have URIs (at least there's no one-to-one mapping unless we define it ourselves). The entire paragraph in section 16 needs to be removed or rewritten. I agree. > - Continue to use the term URI in IANA considerations, where the property > name and lock token URIs are discussed. Again -- needs to be fixed. In particular, property names are not URIs at all (but rather a pair consisting of a URI and a property name) and lock tokens should be called URNs, not URIs. Cheers, Geoff
Received on Thursday, 11 July 2002 08:53:48 UTC