RE: Draft [URL] reference update to informative text

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

There is one other sense of stability that is less consequential but still worth caring about, viz. stability of section IDs or vocabulary used, for when the referencing spec wants to deep-link or make use of the concepts involved directly. That's a different story, and is largely about how the editors of the referencing spec and the referenced spec work together (similar to how the maintainer of a software package works together with those depending on it). I agree it's not clear in general that how W3C specs work makes them fit to reference WHATWG specs in this kind of deep-linking manner. Hopefully that will evolve over time; Jeff recently raised an issue that has the potential of moving us toward that world [4]. But in the specific case of HTML5 and URL, as mentioned, the coupling is so small and well-factored that it's just not an issue. And likely other cases, IMO.

(An alternative for the meantime is for W3C specs to reference living WHATWG specs alongside commit snapshots of WHATWG specs---see [7]---as a way of saying "go look at the living standard, but if the term 'foo' has disappeared from it and we haven't had time to fix our referencing spec in that regard, go back to the old commit so you can at least get a general idea of what we're talking about.")

[1]: https://streams.spec.whatwg.org/#status

[2]: https://books.spec.whatwg.org/#status

[3]: https://whatwg.github.io/loader/#status

[4]: http://www.w3.org/community/w3process/track/issues/141

[5]: https://html.spec.whatwg.org/multipage/embedded-content.html#the-video-element

[6]: https://github.com/whatwg/streams/issues/216

[7]: http://lists.w3.org/Archives/Public/public-w3process/2014Oct/0066.html

Received on Wednesday, 8 October 2014 18:04:55 UTC