Re: Draft [URL] reference update to informative text

On Oct 8, 2014, at 11:04 AM, Domenic Denicola wrote:

> From: Chris Wilson [mailto:cwilso@google.com] 
> 
>> That said - man, it sure would help me feel better about the stability and applicability if the WHATWG had any kind of addressing of the places where this spec (and others) fail those NRP principles - say, a stability section, or a clear "this is how this is likely to change in the future".  Or a stable snapshot that doesn't have an derogatory lawyercat title, but does have a clear "you probably want the living standard over here" pointer.  Because right now, the answer in every case has been "everything can change at any time", which is a concerning failure.
> 
> Well, the answer is certainly more nuanced than that. (We also discussed this during the TAG F2F, so I feel it important to relay here, to the extent the minutes may not cover it.) It's "anything could change *as long as it doesn't break the web*." That guarantee is actually a very strong one, and also probably the strongest you'd want to make---anything stronger would unnecessarily constrain evolution and bugfixes.
> 
> Relatedly, I'd like to call your attention to the difference between Living Standards like URL, HTML, DOM, and XHR versus "soon to become living standards" like Streams [1] and Books [2], or "dreams of becoming a living standard" like Loader [3]. We take our commitment to true Living Standards very seriously. While the APIs in Streams might change a bit---in backward-incompatible ways---as they get implemented, the APIs of URL or DOM are not going to change backward-incompatibly. They're very stable in that regard. We're hoping to roll out better indications of this sort of stability across many WHATWG specs, e.g. based on caniuse data [5] or test results [6].

That's quite remarkable given that there are no known implementations of
the URL "Living Standard", its interface names were recently changed
(e.g., URLUtils), and the only bits that have been verified as interoperable
are those that overlap RFC3986 and RFC3987.  Even the basic parsing
algorithms are dependent on experimental APIs.

It does, however, have the same level of stability as the HTML
"Living Standard", so at least you are being consistent.

....Roy

Received on Wednesday, 8 October 2014 23:20:38 UTC