Re: Proposal: defer converge with the URL standard to a later release of HTML

Hi Sam,

first, thank you for going through the spec in detail sufficient to make 
a structured proposal. To put things succinctly I don't think we should 
go down that path, but it is very useful to have it fleshed out so we 
can look at it.

On 26/09/2014 15:31 , Sam Ruby wrote:
> While Plan "A" would remain to identify a link that would satisfy the
> reference for [URL] in the existing Proposed Recommendation, there are
> concerns about the technical stability[1] of any current snapshot based
> on the WHATWG URL Standard (this would include any potential snapshot
> hosted by the W3C).  As such, it makes sense to explore a plan "B".

This may not be what you had in mind, but I think that one of the values 
in exploring a "Plan B" is that if the second-best plan proves 
problematic then that has to count in the arbitrage when evaluating 
"Plan A".

To put this differently, for those of us who don't like broccoli the choice:

     A) eating broccoli, or
     B) eating cauliflower

doesn't have the same decision structure as:

     A) eating broccoli, or
     B) jumping off a bridge

I am not saying that Plan B is as bad as jumping off a bridge, that 
would be excessive rhetoric, but I do believe that it does suffer from 
drawbacks of a technical nature that vote strongly in favour of Plan A. 
(That's not even going into the social aspects, expense of resources, 
forking, etc. which we all know about, but we should assume they are there.)

> Note: the plan outlined below would likely require a return to Last all,
> and therefore would likely result in final Recommendation being
> published in February.

Since I made the initial February assessment on this, I wish to qualify 
it: it assumes a very aggressive schedule. I should also note that the 
editors' team has yet to weigh in on this topic which seems like it 
would be fair as the changes need to be carried out by someone :)

> Here are the current references to [URL] in the Proposed Recommendation.
>
>> The following terms are defined in the URL standard: [URL]
>
> Replace with a reference to [RFC3986] and [RFC3987]; for each term, map
> to [RFC3986] and/or [RFC3987]

I think that this is possibly the largest issue with this approach. It 
is not clear to me that the RFCs feature the content necessary to 
(re)define those definitions. It could work for some of them, but it 
would be a stretch to do all. And those are, in turn, used in quite a 
few placed (including some that don't have [URL] and therefore aren't in 
your list). At the very least I would say: there be (technical, large, 
angry) dragons.

>> The Location interface also supports the URLUtils interface. [URL]
>
> Defer to later release (i.e., drop from HTML 5.0)

We've dropped things I really wanted to keep based on bad test results 
and the such, and that's life. But dropping what is essentially a DOM0 
interface that we all know won't break strikes me as crossing a line.

As you said very well in your blog post[0], this isn't a technical 
decision. The URL spec can be unstable all it wants, it can be rewritten 
seven times over, it can be quartered and split and translated into 
Vogon, and things would *still* not break. To me this raises a major red 
flag in trying to address the issue through technical means. It's a sort 
of layer violation if you will.


In case it wasn't clear I strongly favour Plan A :)


[0] http://intertwingly.net/blog/2014/09/16/The-URL-Mess

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Received on Friday, 26 September 2014 14:25:59 UTC