[046-lc-edit-relative-URI] proposed patch

A request has been made to remove all usage of the term relative-URI
from the specification, now listed as issue 046-lc-edit-relative-URI.

The following patch will make that change to draft-06.xml. In spite of
its length, the change remains IMHO editorial in nature.  If you do
not think it is allowable in the author's 48 hours of modifications
prior to RFC publication, or if you disagree with the patch, or if
you feel that this level of churn isn't worth it just to satisfy
confusion, then please tell us now by replying to this message.

Cheers,

Roy T. Fielding                            <http://roy.gbiv.com/>
Chief Scientist, Day Software              <http://www.day.com/>

Index: rfc2396bis.xml
===================================================================
RCS file: /home/cvs/ietf-uri/rev-2002/rfc2396bis.xml,v
retrieving revision 1.121
diff -u -r1.121 rfc2396bis.xml
--- rfc2396bis.xml	17 Jul 2004 22:26:41 -0000	1.121
+++ rfc2396bis.xml	28 Aug 2004 00:42:16 -0000
@@ -470,8 +470,8 @@
  <iref item="relative" primary="true"/>
  <t>
  It is often the case that a group or "tree" of documents has been
-constructed to serve a common purpose, wherein the vast majority of 
URIs
-in these documents point to resources within the tree rather than
+constructed to serve a common purpose, wherein the vast majority of URI
+references in these documents point to resources within the tree 
rather than
  outside of it.  Similarly, documents located at a particular site are
  much more likely to refer to other resources at that site than to
  resources at remote sites.
@@ -484,7 +484,7 @@
  changing any of the relative references.
  </t>
  <t>
-A relative URI reference (<xref target="relative-uri"/>) refers to a
+A relative reference (<xref target="relative-ref"/>) refers to a
  resource by describing the difference within a hierarchical name space
  between the reference context and the target URI.  The reference 
resolution
  algorithm, presented in <xref target="reference-resolution"/>, defines
@@ -1158,8 +1158,8 @@
  either be empty or begin with a slash ("/") character.
  If a URI does not contain an authority component, then
  the path cannot begin with two slash characters ("//").
-In addition, a URI reference (<xref target="uri-reference"/>) may begin
-with a relative path, in which case the first path segment cannot
+In addition, a URI reference (<xref target="uri-reference"/>) may be
+a relative-path reference, in which case the first path segment cannot
  contain a colon (":") character.  The ABNF requires five separate rules
  to disambiguate these cases, only one of which will match the path
  substring within a given URI reference.  We use the generic term
@@ -1208,8 +1208,8 @@
  <t>
  The path segments "." and "..", also known as dot-segments, are 
defined for
  relative reference within the path name hierarchy.
-They are intended for use at the beginning of a relative path reference
-(<xref target="relative-uri"/>) for indicating
+They are intended for use at the beginning of a relative-path reference
+(<xref target="relative-ref"/>) for indicating
  relative position within the hierarchical tree of names.  This is 
similar
  to their role within some operating systems' file directory structure 
to
  indicate the current directory and parent directory, respectively.
@@ -1356,13 +1356,13 @@
  resource identifier.
  <iref item="URI grammar" subitem="URI-reference" primary="true"/>
  <iref item="URI grammar" subitem="URI" primary="false"/>
-<iref item="URI grammar" subitem="relative-URI" primary="false"/>
+<iref item="URI grammar" subitem="relative-ref" primary="false"/>
  </preamble><artwork type="abnf">
-   URI-reference = URI / relative-URI
+   URI-reference = URI / relative-ref
  </artwork><postamble>
-A URI-reference may be relative:
-if the reference's prefix matches the syntax of a scheme followed by
-its colon separator, then the reference is a URI rather than a 
relative-URI.
+A URI-reference is either a URI or a relative reference.
+If the URI-reference's prefix does not match the syntax of a scheme 
followed
+by its colon separator, then the URI-reference is a relative reference.
  </postamble></figure>
  <t>
  A URI-reference is typically parsed first into the five URI components,
@@ -1377,20 +1377,20 @@
  </t>
  </section>

-<section title="Relative URI" anchor="relative-uri">
-<iref item="relative-URI" primary="true"/>
+<section title="Relative Reference" anchor="relative-ref">
+<iref item="relative-ref" primary="true"/>
  <iref item="network-path" primary="true"/>
  <iref item="absolute-path" primary="true"/>
  <iref item="relative-path" primary="true"/>
  <figure><preamble>
-A relative URI reference takes advantage of the hierarchical syntax
-(<xref target="hierarchical"/>) in order to express a reference that is
+A relative reference takes advantage of the hierarchical syntax
+(<xref target="hierarchical"/>) in order to express a URI reference
  relative to the name space of another hierarchical URI.
-<iref item="URI grammar" subitem="relative-URI" primary="true"/>
+<iref item="URI grammar" subitem="relative-ref" primary="true"/>
  <iref item="URI grammar" subitem="query" primary="false"/>
  <iref item="URI grammar" subitem="fragment" primary="false"/>
  </preamble><artwork type="abnf">
-   relative-URI  = relative-part [ "?" query ] [ "#" fragment ]
+   relative-ref  = relative-part [ "?" query ] [ "#" fragment ]

     relative-part = "//" authority path-abempty
                   / path-absolute
@@ -1493,7 +1493,7 @@
  <xref target="RFC1535"/>.
  </t>
  <t>
-Since a URI suffix has the same syntax as a relative path reference, a
+Since a URI suffix has the same syntax as a relative-path reference, a
  suffix reference cannot be used in contexts where a relative reference
  is expected.  As a result, suffix references are limited to those 
places where
  there is no defined base URI, such as dialog boxes and off-line 
advertisements.
@@ -1508,7 +1508,7 @@
  <t>
  This section defines the process of resolving a URI reference within
  a context that allows relative references, such that the result is a
-string matching the "URI" syntax rule of <xref target="components"/>.
+string matching the &lt;URI&gt; syntax rule of <xref 
target="components"/>.
  </t>

  <section title="Establishing a Base URI" anchor="base-uri">
@@ -1860,7 +1860,7 @@
     http://a/b/c/d;p?q
  </artwork></figure>
  <t>
-a relative URI reference is transformed to its target URI as follows.
+a relative reference is transformed to its target URI as follows.
  </t>

  <section title="Normal Examples" anchor="relative-normal">
@@ -1899,7 +1899,8 @@
  </t>
  <t>
  Parsers must be careful in handling cases where there are more
-relative path ".." segments than there are hierarchical levels in the
+".." segments in a relative-path reference than there are hierarchical
+levels in the
  base URI's path.  Note that the ".." syntax cannot be used to change
  the authority component of a URI.
  </t>
@@ -1921,7 +1922,7 @@
     "..g"           =  "http://a/b/c/..g"
  </artwork></figure>
  <t>
-Less likely are cases where the relative URI reference uses 
unnecessary or
+Less likely are cases where the relative reference uses unnecessary or
  nonsensical forms of the "." and ".." complete path segments.
  </t>
  <figure><artwork>
@@ -1934,7 +1935,7 @@
  </artwork></figure>
  <t>
  Some applications fail to separate the reference's query and/or
-fragment components from a relative path before merging it with
+fragment components from the path component before merging it with
  the base path and removing dot-segments.  This error is rarely noticed,
  since typical usage of a fragment never includes the hierarchy ("/")
  character, and the query component is not normally used within
@@ -1947,7 +1948,7 @@
     "g#s/../x"      =  "http://a/b/c/g#s/../x"
  </artwork></figure>
  <t>
-Some parsers allow the scheme name to be present in a relative URI 
reference if
+Some parsers allow the scheme name to be present in a relative 
reference if
  it is the same as the base URI scheme.  This is considered to be a
  loophole in prior specifications of partial URI <xref 
target="RFC1630"/>.
  Its use should be avoided, but is allowed for backward compatibility.
@@ -2007,7 +2008,7 @@
  </t>
  <t>
  In testing for equivalence, applications should not directly compare
-relative URI references; the references should be converted to their
+relative references; the references should be converted to their
  target URI forms before comparison.  When URIs are being compared
  for the purpose of selecting (or avoiding) a network action, such as
  retrieval of a representation, the fragment components (if any) should
@@ -2194,7 +2195,7 @@
    <t>Always provide the host, if any, in lowercase characters.</t>
    <t>Only perform percent-encoding where it is essential.</t>
    <t>Always use uppercase A-through-F characters when 
percent-encoding.</t>
-  <t>Prevent dot-segments appearing in non-relative URI paths.</t>
+  <t>Prevent dot-segments from appearing in paths.</t>
    <t>For schemes that define a default authority, use an empty 
authority
       if the default is desired.</t>
    <t>For schemes that define an empty path to be equivalent to a path
@@ -3084,11 +3085,11 @@
                 / path-rootless
                 / path-empty

- URI-reference = URI / relative-URI
+ URI-reference = URI / relative-ref

   absolute-URI  = scheme ":" hier-part [ "?" query ]

- relative-URI  = relative-part [ "?" query ] [ "#" fragment ]
+ relative-ref  = relative-part [ "?" query ] [ "#" fragment ]

   relative-part = "//" authority path-abempty
                 / path-absolute
@@ -3315,7 +3316,7 @@
  and discussion within the W3C Technical Architecture Group.
  </t>
  <t>
-An ABNF rule for URI has been introduced to correspond to the
+An ABNF rule for URI has been introduced to correspond to one
  common usage of the term: an absolute URI with optional fragment.
  </t>
  </section>
@@ -3349,19 +3350,21 @@
  abs_path, rel_path, path_segments, rel_segment, and mark rules.
  All references to "opaque" URIs have been replaced with a better
  description of how the path component may be opaque to hierarchy.
+The relativeURI rule has been replaced with relative-ref to avoid
+unnecessary confusion over whether or not they are a subset of URI.
  The ambiguity regarding the parsing of URI-reference as a URI or a
-relative-URI with a colon in the first segment has been eliminated
+relative-ref with a colon in the first segment has been eliminated
  through the use of five separate path matching rules.
  </t>
  <t>
  The fragment identifier has been moved back into the section on
-generic syntax components and within the URI and relative-URI
+generic syntax components and within the URI and relative-ref
  rules, though it remains excluded from absolute-URI.
  The number sign ("#") character has been moved back to the reserved set
  as a result of reintegrating the fragment syntax.
  </t>
  <t>
-The ABNF has been corrected to allow a relative path to be empty.
+The ABNF has been corrected to allow the path component to be empty.
  This also allows an absolute-URI to consist of nothing after the 
"scheme:",
  as is present in practice with the "dav:" namespace <xref 
target="RFC2518"/>
  and the "about:" scheme used internally by many WWW browser 
implementations.

Received on Saturday, 28 August 2004 00:54:24 UTC