RE: Issue: URI_URL, proposed changes

   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