- From: Martin Duerst <duerst@w3.org>
- Date: Sun, 29 Aug 2004 15:32:59 +0900
- 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 <URI> 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 UTC