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

On 09/26/2014 10:25 AM, Robin Berjon wrote:
> 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.

Indeed.  However, based on your response, it needs to be fleshed out 
more.  Please take the comments below in the spirit of "Devil's 
Advocate" as I continue to stand by my recommendations as described in 
my blog post [0].

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

You are conflating editor with author.  See [1].

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

Can you provide even a single example?  Otherwise, this comes off as FUD.

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

Alternate proposal would be to inline that definition.  To be clear: 
that would be for HTML 5.0.  Ideally, this would be one of the items 
split out "After 5"[2].

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

As do I.  However:

http://www.bestofsherlock.com/top-10-sherlock-quotes.htm#impossible

For more context, we have been discussing the idea of going to more or 
less annual releases; and I know that you personally have been an 
advocate for doing so.

HTML 5.0 went to PR in 3Q14.  Ideally HTML 5.next (provisionally: HTML 
5.1 at this time) PR would occur in 2H15.  If 5.0 is delayed enough it 
either essentially becomes 5.next, along with the set of problems that 
that opens up; either that or it becomes a late 2015 snapshot of the web 
as it existed in early to mid 2014.

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

[1] http://lists.w3.org/Archives/Public/public-html/2014Sep/0073.html

[2] http://lists.w3.org/Archives/Public/public-html/2014Sep/0018.html

- Sam Ruby

Received on Friday, 26 September 2014 14:58:48 UTC