W3C home > Mailing lists > Public > public-iri@w3.org > August 2004

New issue relative-IRI-46 (was: [046-lc-edit-relative-URI] proposed patch)

From: Martin Duerst <duerst@w3.org>
Date: Sun, 29 Aug 2004 15:32:59 +0900
Message-Id: <4.2.0.58.J.20040829152358.05c35ed8@localhost>
To: public-iri@w3.org
Cc: Ted Hardie <hardie@qualcomm.com>

I'm forwarding this to the IRI list to open issue relative-IRI-46
(http://www.w3.org/International/iri-edit#relative-IRI-46). The
resolution of this issue depends on whether and how this will be
resolved for RFC2396bis, so this issue is currently pending.
I have taken the libery to jump issue number 45 to allign the
issue numbers for both drafts on this matter :-).

Regards,    Martin.

>Date: Fri, 27 Aug 2004 17:54:45 -0700
>From: Roy T.Fielding <fielding@gbiv.com>
>To: uri@w3.org
>Subject: [046-lc-edit-relative-URI] proposed patch
>X-Archived-At: 
>http://www.w3.org/mid/DA8C5508-F88C-11D8-9EF3-000393753936@gbiv.com

>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 Sunday, 29 August 2004 06:33:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 30 April 2012 19:51:53 GMT