W3C home > Mailing lists > Public > uri@w3.org > August 2004

Re: Relative URI or relative URI reference

From: Roy T. Fielding <fielding@gbiv.com>
Date: Thu, 19 Aug 2004 12:54:41 -0700
Cc: uri@w3.org
To: Elliotte Rusty Harold <elharo@metalab.unc.edu>
Message-Id: <9C494D1A-F219-11D8-BD91-000393753936@gbiv.com>

> Of course, this occurs in the fuzzy world of human language where 
> context is critical for sorting these things out so it's a bit of a 
> canard. In the domain of technical specifications we're operating in 
> here, it's possible to be much more precise, unambiguous, and clear. 
> Indeed it is critical to do so. The current draft fails to achieve 
> this. It is unclear, ambiguous, and imprecise. It cannot be properly 
> understood without being familiar with the discussions that went into 
> it, and the intentions of its authors.

On what basis do you come to that conclusion?  Because you don't like
the name of a section heading and one ABNF rule?  Allow me to quote:

Section 1:

    A URI is an identifier, consisting of a sequence of characters
    matching the syntax rule named <URI> in Section 3, that enables
    uniform identification of resources via a separately defined,
    extensible set of naming schemes (Section 3.1).

Section 1.1.1:

    Each URI begins with a scheme name, as defined in Section 3.1, that
    refers to a specification for assigning identifiers within that

Section 3:

    The generic URI syntax consists of a hierarchical sequence of
    components referred to as the scheme, authority, path, query, and

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

4.  Usage

    When applications make reference to a URI, they do not always use the
    full form of reference defined by the "URI" syntax rule.  In order to
    save space and take advantage of hierarchical locality, many Internet
    protocol elements and media type formats allow an abbreviation of a
    URI, while others restrict the syntax to a particular form of URI.
    We define the most common forms of reference syntax in this
    specification because they impact and depend upon the design of the
    generic syntax, requiring a uniform parsing algorithm in order to be
    interpreted consistently.

4.1  URI Reference

    URI-reference is used to denote the most common usage of a resource

       URI-reference = URI / relative-URI

    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.

Section 4.2  Relative URI

    A relative URI reference takes advantage of the hierarchical syntax
    (Section 1.2.3) in order to express a reference that is relative to
    the name space of another hierarchical URI.

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

       relative-part = "//" authority path-abempty
                     / path-absolute
                     / path-noscheme
                     / path-empty

    The URI referred to by a relative reference, also known as the target
    URI, is obtained by applying the reference resolution algorithm of
    Section 5.

I strongly suggest that you should limit your comments to the actual
content of rfc2396bis rather than some perceived experiences you
might have had in the *past*.

> It is simply confusing to readers to say that "absolute URI" is a 
> synonym for "URI"

Good, because that would be a false statement.

>  and that a "relative URI" is not in fact a "URI".

It is a part of the generic syntax as being one of the things
found in a URI-reference.  If you have to say anything more than
that, then you are having a philosophical discussion rather than
a technical discussion.  There is no ambiguity in rfc2396bis that
I am aware of, and I suspect that if you would avoid trying to
reinterpret the specification into a common set of misconceptions,
then nobody would be confused.

Received on Thursday, 19 August 2004 19:54:28 UTC

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