Re: w3process-ISSUE-124 (WHATWG-blacklist): Normative Reference policy should explicitly black list WHATWG specs [Normative Reference Policy]

On Fri, 3 Oct 2014, Tim Berners-Lee wrote:
> 
> https://whatwg.org/specs/url/2014-07-30/
> 
> July 2014 Snapshot of the URL Standard for the Purposes of Patent Lawyers and Government Officials

This is indeed the title of that document. It's an important title, as it 
serves a critical purpose: preventing anyone from thinking that this is a 
document that should be referenced by anyone other than patent lawyers and 
government officials.

Why patent lawyers and government officials?

Well, it turns out that in the years of asking people why they want stale 
snapshots of specs, only two reasons that make any remote sense have ever 
been presented to me [1]:

1. Patent lawyers, for litigation purposes, need to be able to reference 
specific text, so that courts can make judgements; court cases tend to 
last years, over which a standard may well evolve dramatically or even 
become obsolete, but the court system, run by government officials, only 
wants to make judgements for the precise time for which the case applies.

2. Governments frequently write contracts that need to refer specific 
versions, for political reasons. These contracts are effectively 
meaningless (it's not like all the people writing contracts that said 
"must write a compliant HTML4 site" ever meant it; they wanted people to 
write modern HTML that violates all kinds of HTML4 rules, like they wanted 
people to assume media="" defaulted to "all" not to "screen" as per HTML4, 
or they wanted people to use modern features like <video>), but, these 
being governments, there's no way to negotiate sanity into the contracts, 
they just have to be that way and are their specifics then ignored with a 
nudge-nudge wink-wink approach.

Now in theory both of these could be resolved by pointing to repository 
versions -- for example, the HTML spec has been through over 8800 
different versions each of which could be individually referenced -- but 
patent lawyers and government officials both work in environments where 
that would, for some reason, be unacceptable.

So, we're left with having to make these snapshots.

BUT, snapshots are terrible for interoperability. Implementations 
referencing old documents leads to implementation bugs, leads to lack of 
compatibility, basically, snapshots for Web techs are actively harmful to 
the goal of any standards organisation, namely, interoperalibily. So it's 
critical that any standards organisation be really careful to not spread 
confusion by having multiple versions of its specifications, or, if it 
does, be exceedingly unambiguous in its labeling to make sure that nobody 
in their right mind, other than patent lawyers and government officials, 
would ever consider referencing such a specification.


> I understand that this is the best which could be obtained as a document 
> to be co-branded by W3C and WhatWG

I've no idea if it's the best. No better proposal has been made that I'm 
aware of, though.


> that after some attempts to negotiate, Hixie refused to have that text 
> removed.

What I refused to do (after initially incorrectly agreeing to do) is to 
change a snapshot, because doing so defeats the entire point of making 
snapshots and would discredit the entire concept that the snapshots are 
unchanging and can be referenced by lawyers and government officials as a 
single unchanging fixed point.

I don't think anyone would object to making a new snapshot for patent 
lawyers and government officials, even with a different title or styling, 
so long as it was made crystal clear to any reader that no spec should 
reference this document, and that no implementor should ever consider 
using this document as a reference.

Fundamentally, the core value at play here is fostering interoperalibity. 
Everything else here is a direct result of starting from that axiom. For 
instance, snapshots harm interoperability on the Web.


> I find the text extremely disrespectful, and childish.

I don't understand why. It certainly was in no way intended that way. It's 
intended as a quite literal statement of the audience of the spec.

Note that "after some attempts to negotiate", the W3C refused to do any 
number of things that I find "extremely disrespectful, and childish", for 
instance:

 - the W3C continues to fork our work (especially disrespectful)

 - the W3C continues to fight referencing our work (childish)

So I guess this goes both ways.


> Are those around the world looking to see how the technology developers 
> of today are handling what is in fact the key primary specification of 
> the web to see that as their best effort?

The key specification of URLs is not that stale snapshot, it's:

   http://url.spec.whatwg.org/

That is the document that one should reference if one wants to reference 
URLs, not the snapshot. The snapshot would lack bug fixes, it would lead 
to poor interoperability if implemented, it is highly inappropriate to 
cite it as anything but a reference point for patent lawyers and 
government officials.


> Marcos, you asked what sort thing will make it possible for other 
> standards bodies in particular W3C to treat WWG as a peer.  In general, 
> the OpenStand principles are a guide to what will. And this is an 
> example of what won't.

I think it is unfortunate that the W3C continues to live in the mindset 
that snapshots are conducive to the Web's health. In practice, it has been 
clear to most implementors for years that that is an outdated, harmful 
model. However, despite the fact that the W3C continues to exhibit a 
number of behaviours that I, and some others who work primarily in the 
WHATWG, think are misguided [2], I would like to make it clear that we 
continue to regard the W3C as a peer, that we are open to working with the 
W3C, and that we will continue to reference specifications that the W3C 
maintains. We encourage the W3C to join us in the 21st century with more 
modern standards development practices, but in the meantime, we do not 
wish you any ill will.


-- Footnotes --

[1] A number of other reasons have been given for why you might want 
snapshots of specs, but none of them make sense when you get right down to 
it, at least for Web technologies:

 - "we need a snapshot to have interoperability"
   In practice, what you need for interoperability is dictated not by the 
   standards, but by the content; and what is needed by the content is 
   dictated by the existing deployed user agents. With snapshots, if 
   there's something in the snapshot that is wrong -- say, the default 
   value of the media="" attribute is described as being "screen" -- but 
   all the content relies on it being implemented differently -- say, as 
   the value "all" -- then the reality is that what has to be implemented 
   for interoperability is not what the snapshot says. That's why 
   implementors have to follow living standards, not snapshots. It's why 
   the HTML4 spec harmed interoperability, rather than helped it, for 
   years -- it keeps claiming, to this day, that "media" defaults to 
   "screen" rather than "all". 

 - "we need a snapshot to know what we can use"
   Again, what authors can use is dictated not by the standards, in 
   practice, but by the implementations. HTML4, for example, has plenty of 
   things in it that are just not implemented. <object declare>, for 
   instance. You can't look at HTML4 and know what you can use.

 - "snapshots guarantee that the technology won't change from under us"
   The reality is that technologies evolve. XML 1.0 has changed normative 
   requirements 4 times, for example. There's nothing about a snapshot 
   that makes the slightest guarantee that things won't change. URLs have 
   changed, despite being RFC snapshots. The stale HTML5 draft being 
   published by the W3C is woefully out of date even relative to its own 
   5.1 variant, let alone relative to the WHATWG living standard. It's not 
   only guaranteed that HTML will change relative to "HTML5", it's in fact
   already changed, it changed months before it was published as CR, let 
   alone REC.


[2] Here's an incomplete list of things I believe are misguided about the 
way the W3C goes about developing specifications:

 - continuing to make snapshots and mislead implementors into thinking 
   they should be considered as meaningful

 - having active private mailing lists

 - having a paid membership system

 - working on DRM

 - not allowing people to reuse spec text in their GPL software

 - not allowing people to easily fork W3C specs if they think the W3C is 
   misguided [3]

 - publishing multiple divergent versions of W3C specs without any clear 
   guidance on what version is the one being maintained that browser 
   vendors should follow -- e.g. see how many versions of the canvas spec 
   I saw in March:
      http://damowmow.com/temp/canvas-specs
   I noticed the same problem at a smaller scale with the HTML5.x specs
   yesterday -- literally half a dozen or more specs with none of them
   having a clear indication that they're obsolete.

 - having a list whose entire purpose is just to talk about process

 - having meetings (both face-to-face and teleconferences), which prevent 
   full participation from people who are impoverished or can't travel

 - having specifications without a single clear owner

 - using consensus, rather than technical arguments, to make decisions

 - using an elaborate tiered decision-making process

 - having specs with unnecessary compromises intended to achieve cloture
   or to meet arbitrary deadlines or rules

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 3 October 2014 17:25:35 UTC