Re: Draft [URL] reference update to informative text

On 11/01/2014 04:59 PM, Domenic Denicola wrote:
> 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 would be thrilled if it turns out to be the case.

> 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 disagree.  Anne has already accepted pull requests.  That's not the 
issue.  The issue is your first bullet:

> 1. Figure out what modifications it would take to the parsing algorithm to make your hot pink rows into pale green or gold. Unless they are *exceedingly* complicated, I imagine Anne would accept a pull request for those.

Which I find in stark contrast with Anne's comment:

> That is not to say that documenting how things actually are is not
> worthwhile, it's just not what we do.

Hopefully I'm just getting this out of context.  I suspect not.  Either 
way, I would like to find out sooner rather than later.

>> 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 :).

Fair point.  I will say, however, that may have found the way that I 
have chosen to approach and present the differences to be both an eye 
opener and valuable.

>> 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?

The differences may be substantial from an implementation perspective, 
but from a content producer point of view will be "on the margins". 
More specifically, there likely be negligible differences between how 
existing deployed content would be interpreted.

>> 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.

I'd describe it slightly differently: I've encountered a speed bump and 
would like advice on whether to go over or around that bump.

> 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.

Again, whatever the differences are with the IETF RFCs (I'll note that 
"old" may be viewed as pejorative, and I've omitted that word), that's 
not the reason for my question to you, Anne and the TAG.  I'm 
specifically looking to challenge:

 > That is not to say that documenting how things actually are is not
 > worthwhile, it's just not what we do.

Like you, I'd encourage people to read the quotes in their original context.

Back to your email:

> 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.

Agreed.

> 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. -

That is indeed the way I have been operating.  And both Anne and I agree 
on some changes that should be made after that.  The question is how to 
proceed from there.

> 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.

Agreed.

> 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 proceses 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.

The amount of work doesn't concern me.  But I'd like to get feedback on:

"That is not to say that documenting how things actually are is not
worthwhile, it's just not what we do."

There are plenty of places where what has been spec'ed doesn't match how 
things actually work.  I've already color coded the results so you can 
see for yourself.

> [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

- Sam Ruby

Received on Saturday, 1 November 2014 21:35:01 UTC