Re: resolving the URL mess

On Fri, Oct 3, 2014 at 12:18 PM, Sam Ruby <rubys@intertwingly.net> wrote:
> On 10/03/2014 06:39 AM, David Sheets wrote:
>>
>> On Fri, Oct 3, 2014 at 2:02 AM, Austin William Wright <aaa@bzfx.net>
>> wrote:
>>>
>>>
>>>
>>> On Thu, Oct 2, 2014 at 11:07 AM, Sam Ruby <rubys@intertwingly.net> wrote:
>>>>
>>>>
>>>> On 10/02/2014 06:05 AM, David Sheets wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Anne, Dave Thayer, Sam Ruby, John Klensin come to mind…
>>>>>
>>>>>
>>>>> I believe that when we have something to show, we should entice them to
>>>>> join us.
>>>>
>>>>
>>>> +1
>>>>
>>>> At the moment, a non-existent spec doesn't solve any problem that I
>>>> currently have.  That's not meant to discourage or encourage you to
>>>> produce
>>>> a spec, but merely an agreement that the time that I would get
>>>> interested is
>>>> when you have something to show.
>>>>
>>>> For what it is worth, examples of problem I do have:
>>>>
>>>> 1) Neither RFC 3986 nor RFC 3987 define the content you will find here:
>>>> https://url.spec.whatwg.org/#api
>>>
>>>
>>> I'm fully behind a standard IRI/URI parsing interface. Let's just release
>>> a
>>> spec that's dedicated to a WebIDL interface for representing and
>>> performing
>>> operations on URIs/IRIs, though. There's no reason it needs to be
>>> combined
>>> into RFC3986/7, any more than XML/HTML and the DOM API need to be
>>> combined.
>>
>>
>> A WebIDL interface for URI manipulation would certainly be desirable
>> but I'm uncertain if it should be within the scope of this group.
>> Specifically, I worry that attempting to define a WebIDL interface
>> before having a specification covering the existing and aspirational
>> behavior of deployed systems may lead us astray. I think a WebIDL
>> interface need not be bundled with a specification of the functions on
>> URI strings and their interpretation, as you say.
>
>
> Understood, but be aware that unless that work is done, that makes this
> effort less relevant to me.

Which work are you referring to? Do you mean the work of specifying
the behavior of existing interfaces? Or do you mean the work of
designing a WebIDL API to be used by JavaScript implementations?

I believe we absolutely should specify the behavior of interfaces. I
am less convinced that the design of a JavaScript (WebIDL) API is
reasonable to expect from this group until we see browser vendor
buy-in. If the browsers write up and roll out a WebIDL API, we will
report on its semantics at length. If we have buy-in, we may make
suggestions or influence a deployed API. I am perfectly happy to have
anyone who wants to work on such an API do so in this group and I will
joyfully help them in their task. I am only cautious regarding this
kind of work for the simple reason that the specification of the
functions *any* API exposes should be our goal and the design work of
a WebIDL API may be wasted without vendor support.

Whether or not we deliver the deployed JavaScript (WebIDL) API is not
a measure of our success in these specification efforts.

> The HTML specification is going to reference a specification for link and
> anchor href manipulation, and manipulation includes parsing and
> serialization.  Those rules, in turn need to be consistent with how user
> agents actually parse things purported to be links in the wild.
>
> I don't care if those links are called URIs or URLs.  I do care that the
> spec that the HTML specification references defines the interface in terms
> that web browsers implement, and frameworks like node.js emulate.
>
> Certainly, that work could be layered on top of the work defined of the work
> envisioned here.  But only if the rules defined here are compatible.

I believe we should try very hard to produce tools, techniques, and
documents that are compatible with any specification that ends up
adopted.

> Here's an analysis of the current incompatibilities between the WHATWG
> definition of URL parsing and the RFC 3986/7 definition of URI parsing:
>
> http://intertwingly.net/blog/2014/10/02/WHATWG-URL-vs-IETF-URI
>
> And here are test results for the WHATWG URL definition:
>
> http://w3c.github.io/test-results/url/all.html

Those are some very interesting links that underscore the enormity of
the tasks we face. I believe test harness creation for a broad range
of implementations (see
<https://github.com/urispec/urispec/wiki/Implementations-and-Use-Cases>
for a first pass at collecting implementations) is a crucial step in
data-driven specification decisions. Creation of such a tool is itself
a non-trivial task.

> There is plenty of room for improvement.

Indeed. I look forward to having your perspective in this and future
discussions and I appreciate all of the work that you have already
done.

What would be your ideal URI specification?

David

Received on Friday, 3 October 2014 13:07:51 UTC