- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Mon, 24 Aug 2009 17:15:59 -0700
- To: Dan Connolly <connolly@w3.org>
- Cc: "public-html@w3.org WG" <public-html@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