Re: [url] Requests for Feedback (was Feedback from TPAC)

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.

....Roy

Received on Friday, 5 December 2014 21:35:36 UTC