W3C home > Mailing lists > Public > public-html@w3.org > August 2009

Re: ISSUE-56: urls-webarch - suggest closing on 2009-09-03

From: Roy T. Fielding <fielding@gbiv.com>
Date: Mon, 24 Aug 2009 17:15:59 -0700
Message-Id: <2EC43847-BFF0-42D8-AAC9-B9EAC53F0182@gbiv.com>
Cc: "public-html@w3.org WG" <public-html@w3.org>
To: Dan Connolly <connolly@w3.org>
On Aug 24, 2009, at 6:41 AM, Dan Connolly wrote:

> On Fri, 2009-08-21 at 10:18 +0200, Julian Reschke wrote:
>> Maciej Stachowiak wrote:
> [...]
>>>>> 2) Replace term URL with something either matching IRIbis or at  
>>>>> least
>>>>> not conflicting.
>>>>
>>>> Yes.
>>>
>>> http://www.w3.org/Bugs/Public/show_bug.cgi?id=7392
>>
>> This one already has been set to "WONTFIX" by the author.
>
> A comment with the WONTFIX includes:
>
> | The real solution is for the URI and IRI specs to be merged, for the
> URI spec
> | to change its definitions to match what "URL" is defined as in  
> HTML5 (e.g.
> | finally defining error handling as part of the core spec), and  
> for everyone to
> | stop using terms other than "URL".
>
> I think that's an interesting idea, if anybody is serious about
> taking it up. I don't know how long it would take... I can't imagine
> it happening in time for last call.

It will never happen.  The comment is based on the theory that
browser error handling is the center of the universe, which has
been proven false many times.  Standardizing on that would cause
the other thousand types of application to be non-compliant.

It is also completely unnecessary because the URI spec doesn't
define "whatever occurs inside a reference" (as HTML5 has redefined
URL to be) but rather how to parse and manipulate a URI reference
after it has been obtained from the context.  How one gets from the
context (document, attribute, location bar, etc.) to a URI reference
is entirely defined by the context.  Only the context can say what
delimits the string, whether the string only contains one
reference or perhaps more than one separated by whitespace,
the character encoding of the string, whether additional
data is to be appended to form the URI reference (e.g., ismap
and form), and how that data is encoded for the URI reference.

Calling the reference string a URL is absurd because it isn't
uniform and is not suitable for transmission in, for example,
an HTTP request.  There is still a lot of documentation out
there about URLs and their transmission on the wire and in
formats other than HTML -- it would be a grave architectural
error to allow such inconsistency to be perpetrated on nothing
other than a single editor's whim.

The reference string is not a URL -- it is a string in the document
character encoding that must go through several transformations
before becoming a URI reference, and only then do the URI specs
apply in regards to relative resolution and syntax constraints.
It is relatively easy to specify the reference processing algorithm
in terms that are entirely defined by HTML5 right up until the
string becomes a URI reference.

Instead, the editor chose to thumb his nose at the IETF standards
process and redefine the term URL in a way that is completely
inconsistent with the past 16 years of Web history.  If the
Director doesn't block that from being published as a Rec,
then I see no reason for the W3C to exist.

....Roy
Received on Tuesday, 25 August 2009 00:16:26 UTC

This archive was generated by hypermail 2.3.1 : Friday, 10 October 2014 16:24:51 UTC