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

Fwiw: I also prefer just moving on right now with plan A.

BTW: this discussion should probably be on html-admin .

And finally a bit of an orthogonal rant: I think that if all w3c specs had
references to where their development continues (i.e. even rec specs have a
link to their "living spec"/editor version), that could solve a lot of
these reference problems. If such continued development is in the WHATWG,
so be it - the WHATWG is now a CG of the w3c so should be trusted as such.
After all, rec docs are merely "releases", i.e. well assessed snapshots.

Best Regards,
Silvia.
On 27 Sep 2014 00:27, "Robin Berjon" <robin@w3.org> 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.
>
> 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
>
>