- From: Sam Ruby <rubys@intertwingly.net>
- Date: Fri, 05 Dec 2014 17:34:30 -0500
- To: "Roy T. Fielding" <roy.fielding@gmail.com>
- CC: Mark Nottingham <mnot@mnot.net>, public-ietf-w3c@w3.org, Philippe Le Hegaret <plh@w3.org>, Wendy Seltzer <wseltzer@w3.org>
On 12/05/2014 02:48 PM, Roy T. Fielding wrote: > On Dec 5, 2014, at 10:53 AM, Sam Ruby wrote: >> On 12/05/2014 12:49 PM, Roy T. Fielding wrote: >>> On Dec 5, 2014, at 8:52 AM, Sam Ruby wrote: >>> >>>> Mark, thanks for the support, but I think that this is a matter that needs a bit more clarity and wide review. >>>> >>>> PLH, Wendy, as the official W3C liaisons[1] to the IETF, I asking you to officially request that the IETF take a position on this subject. >>> >>> In order for the IETF to take a position on the subject, it would >>> require an Internet draft stating the position and an appropriate >>> public review. Even so, at best what you would get is a bunch of >>> opinions on what might be a reasonable way forward. >>> >>> IMO, a solution would be to just remove the bits of the URL spec >>> that say it redefines RFC3986 (because it doesn't), name the spec to >>> something reasonable (like "URL Object and Processing References in HTML"), >>> and then complete the work you have started on making the parsing >>> algorithm for references more closely reflect deployed implementations. >>> I don't think the IETF protocols that depend on RFC3986 would have >>> any problem with such a document, and it would satisfy the needs of HTML. >> >> Examples of non-HTML implementations: >> >> http://nodejs.org/api/url.html >> https://github.com/smola/galimatias >> http://servo.github.io/rust-url/url/index.html > > Yes, and each of those referenced docs would be greatly improved by not > using the same term URL for five different things. The fact that > they do such contortions right now is purely because they are trying > to reuse the same terms as the WHATWG spec, with spectacular confusion > as a result. > >>> However, it is still ridiculous to claim that URI != URL in Web parlance. >>> URL is and always has been the subset of URI that can be used as a locator, >>> which most people understand to be equivalent to the set of all URI once >>> they figure out how HTTP works. Changing the existing term URL to fit the >>> definition of a reference is just plain confusing, even within the HTML >>> specifications. I know because I tried to do that myself in the early >>> drafts of RFC1808. If the goal is to produce quality specifications, >>> we should expect the terms to be used correctly. >> >> Historical considerations aside, modern releases of Chrome, Firefox, Internet Explorer, and Safari have an object/function named "window.URL". I'm not optimistic that this can be changed at this point. > > What does that have to do with anything? The DOM object name doesn't > define the entire space. If it did, then every occurrence of a URL > within the DOM under a different object name would require a new standard > to define it. > > I don't see any problem with continuing to use URL as the API name > for an object that contains a parsed reference and produces a URL string. > That should be distinguishable by context (e.g., code). What I have > a problem with is the notion that both the input and the output of > those processes is a URL. That is madness. There is a reason why > the input is called href or src, not URL. I've opened https://www.w3.org/Bugs/Public/show_bug.cgi?id=27528 on this. > ....Roy - Sam Ruby
Received on Friday, 5 December 2014 22:35:19 UTC