W3C home > Mailing lists > Public > uri@w3.org > September 2003

suggestions for path component clarification

From: by way of Martin Duerst <mike@skew.org>
Date: Thu, 25 Sep 2003 08:35:06 -0400
Message-Id: <4.2.0.58.J.20030925083456.03a52e20@localhost>
To: uri@w3.org




Hello,

This is in reference to
http://cvs.apache.org/viewcvs.cgi/*checkout*/ietf-uri/rev-2002/rfc2396bis.ht 
ml?rev=1.64

Appendix D.2 says

   'All references to "opaque" URIs have been replaced with
   a better description of how the path component may be
   opaque to hierarchy'

yet section 3.3 starts off with

   "The path component contains hierarchical data..."

The next paragraph says

   "The path consists of a sequence of path segments separated
   by a slash ("/") character."

but then goes on to say

   "the ... path may be empty (zero length) or opaque..."

IMHO this is not doing a very good job of defining the path component,
nor is it educating the reader that "path" in this spec doesn't always
mean the kind of path that pretty much everyone, even my mom, thinks
of when one refers to a path.

I never liked overloading the term "path" to mean "an absolute or relative
URL path, or maybe a URN opaque part". It seems like we're (well, you're)
trying to retain URL-specific terminology when you talk about URIs
generically, even if the URI is a URN where such terminology is
inappropriate, if not completely unintuitive.

As such, in 4Suite I chose to implement a URI parser and validator in a
way that distinguishes between a path and an opaque part as separate URI
components. It's not too late to change my implementation (that's why I
am here), but I do want to register my opposition to the direction the
spec is moving.

At least, if the ambiguous semantics of "path" are to be set in stone, I
would much rather see a replacement of the term, rather than overloading
this one that is pretty much universally understood to have a narrower
meaning than the one you are defining here.

Short of that, I suggest starting section 3.3 with something like

   The path component of a URI, along with data in the optional query
   component, serves to identify a resource within the scope of that URI's
   scheme and naming authority (if any).

   The path typically contains hierarchical data in the form of path
   segments separated by a slash ("/") character, but may sometimes be
   empty (zero length) or opaque (not containing any "/" separators).
   A path is always defined for a URI, regardless of whether or not it
   is hierarchical, empty, or opaque.

   There is no specific "path" syntax production in the generic URI
   syntax. Instead, the path component is that part of the parsed URI
   string matching either the abs-path or the rel-path production,
   since they are mutually exclusive for any given URI and can be
   parsed as a single component. The rel-path production encompasses
   relative, empty and opaque paths. The path is terminated by the
   first question-mark ("?") or number-sign ("#") character, or by the
   end of the URI.

   In a hierarchical path, the path segments "." and ".." are defined
   for relative reference within the path name hierarchy.
   [...]

- Mike
Received on Thursday, 25 September 2003 08:35:57 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:06 UTC