RE: Draft [URL] reference update to informative text

From: Sam Ruby [mailto:rubys@intertwingly.net] 

> Domenic, what you describe indeed does describe the way I would like to proceed.  And based on the people I met with this past week at TPAC -- including members of the TAG, AC, AB, employees of browser vendors, people who would primarily describe themselves as members of the WHATWG, and people who would primarily describe themselves as members of the IETF.
>
> I would like to work with *ALL* of them.
>
> My problem is that my read is that Anne feels that this contradicts "most WHATWG work", and "it's just not what we do".  You can read his actual words in context here:
>
> http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Nov/0004.html


Unfortunately it seems like you have chosen a few choice words out of Anne's email to put Anne in the worst light possible :(. I am pretty sure that wasn't your intent, but it'd be good to be careful. I'd encourage bystanders on this thread to read the entire linked thread.

I have seen no indication from Anne's messages on whatwg@ that he objects to "what I describe", regarding a plan for submitting pull requests to the URL Standard more in line with browsers with regard to the orange rows. Instead, my perception of his objections are around you trying to integrate the URL Standard with RFC 3986, which he believes is not possible.

> I'm not going to mince words as I want to get quickly back to the work of defining behavior that user agents -- including browser vendors and web servers and libraries alike[1] -- would be willing to converge to.
>
> Anne has repeatedly described his effort as something that hasn't attracted sufficient implementer interest, something that he doesn't have bandwidth for at the moment, and something for which a large portion of the spec is in need of a rewrite.
>
> By contrast, I seem to be having no problems attracting implementer interest,

Links or details please? I haven't seen any changes accepted into implementations yet. I can imagine Anne felt he had no problems attracting implementer interest, until push came to shove :).

> I believe that I have demonstrated that I have bandwidth, and have now written a substantial portion of a proposed replacement.

That's really great!! We should be sure not to lose sight of this.

> I have also made it very clear to everybody that venue choice is not a primary consideration for me.  If this work is welcome at the WHATWG, I would glad to do it there.  If it is not, then I will work wherever I am welcome.
>
> I can't emphasize this enough: it truly matters not to me.  I am producing a specification draft using bikeshed.  With a few lines of metadata change, I would be building a W3C Working Draft instead of a WHATWG Living Standard, with all of the patent and copyright implications that would come with such a change.  But as venue choice isn't a primary consideration for me, that wouldn't be a problem for me.
>
> The two efforts would not largely share spec text.  In fact, outside of the names of external interfaces and the small amount of WebIDL that this specification defines, I don't see a need for overlap.
>
> What would be true, however, is that the behavior that user agents would be expected to comply with would differ substantially.  My expectation is that the expected behavior would match where it comes to matching the realities of deployed content, but would diverge when it comes to matching what user agents do or would be willing to do.

What does this mean, precisely? In the end what matters is which spec is a more accurate documentation of existing implementations and/or target for new implementations and implementations that wish to converge. I don't see how deployed content fits into things?

> Any advice on how to proceed would be appreciated, as I don't want to spend further time on politics, I would much rather be focusing on convergence and interop.

My impression from surveying the situation is that talks between you and Anne have broken down, IMO prematurely. The way you've described the situation causes a gut reaction of "well, Sam is clearly doing all the right things here and Anne is being stubborn, so it's time for a fork of the URL Standard by someone who has the time for it!" But when I step back and survey the evidence, primarily as embodied in your excellent test result tables, the situation doesn't seem so dire yet.

One important issue is that there is no disagreement between you and Anne that speccing URL parsing to reflect the real world is the best path forward. [1] makes it seem like there is such disagreement, but in actuality that disagreement is about your desire to work on something that integrates with old IETF RFCs that do not really reflect on-the-web reality, embodied in your messages by the idea of a separate "URI" spec. I can see where you're coming from politically, but I think it is technically counterproductive. I definitely don't believe a separate URI concept is valuable or viable.

If you insist on attempting this *as part of your changes to URL*, then you're likely going to reach an impasse. However if you wanted to produce some separate document that documents the divergences, I think in [2] Anne indicated that would be a good idea, and I wholeheartedly agree, even if it ends up being of only historical and not technical interest.

From this perspective, there's more valuable agreement present than disagreement. And so in terms of advice, I would suggest concretely:

- Submitting pull requests for holistic whole-document changes to URL that do not cause any behavior or normative requirement change but lay the appropriate groundwork, e.g. converting to Bikeshed, converting to functional style, or similar.
- Once the dust has settled on these, start submitting targeted algorithm changes to fix more rows in the table.
- Finally, I think Anne has repeatedly emphasized that the hardest part of this work is getting browsers to accept that changes are necessary to their URL parsers, and making those changes. You said you have implementer interest, in which case, I would proceed by focusing on using that interest to generate convergence. If this step doesn't work, it's unclear how much the rest of the effort is worth.

I realize this is more work than just publishing your own GitHub fork, in whichever standard organization will accept it. Hopefully it's not what you see as "politics," but instead the normal software development process of working with a maintainer of an existing piece of "software" to get your sometimes-patches accepted and integrated into the canonical repo. Maybe things will break down, and a fork will be necessary, but I don't think we're there yet.

[1]: http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Nov/0004.html

[2]: http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Nov/0002.html

Received on Sunday, 2 November 2014 13:55:12 UTC