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

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