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

On Mon, 6 Oct 2014, David (Standards) Singer wrote:
> On Oct 6, 2014, at 14:57 , Ian Hickson <ian@hixie.ch> wrote:
> > 
> > I disagree that that is a priori important. The purpose of the 
> > snapshot is just to provide a reference for patent lawyers in cases 
> > regarding patent infringement, and government officials in contracts 
> > whose precise details are ignored (as discussed in my last e-mail).
> 
> No, that is a very narrow and intentionally pejorative view.  I 
> encourage you to move beyond it.

I explained the reasoning behind this view in detail earlier. If you think 
that reasoning is incorrect, the best way to convince me would be to 
explain why, not just accurately describe it as "very narrow and 
intentionally pejorative" (which is true, and rather the point).

   http://lists.w3.org/Archives/Public/public-w3process/2014Oct/0036.html

Suggesting I move "beyond" this viewpoint makes a somewhat substantial 
error in understanding regarding the direction in which my opinions on the 
matter have shifted over the past 15 years, though. In reality, if there's 
a further shift, it'll continue to be in the same direction, away from 
"stable" (or "stale") snapshots and more towards the Web's native "living" 
format (as used by wikis and other modern collaborative platforms). 
Specifically, I think software patents are misguided, and once we manage 
to get rid of those, half the reason for snapshots to still exist will be 
gone. The only other reason, government officials wanting snapshots to 
refer to in contracts, is hopefully one that will die with evolving social 
norms being more used to evolving standards; there will surely come a 
point where the technology is more important to those writing the 
contracts than their adoption is to those writing the standards. (Indeed, 
we may have already passed that point. If government contracts were the 
only reason for a snapshot spec, I wouldn't bother.)


> > In neither case is the history of the document important. In the 
> > latter case, even the content of the document is unimportant (just as 
> > the contents of HTML4 are unimportant to government contracts today 
> > referencing HTML4).
> > 
> > People who want to browse the history of the URL spec, for example, 
> > wouldn't ever end up at the patent snapshot of the URL spec. They'd 
> > end up
> 
> some version of
> 
> > at the URL spec, which has a "version history" link right at the top.

Not sure what you're trying to say here.


> If you want to stay informed, I suggest you read The Economist. (General 
> reference).  If you want to see the article I am discussing, please read 
> the issue dated June 21st 2013.
>
> If you want to steer clear of legal problems, stay up to date on the 
> law.  If you want to know what Mordred is being prosecuted for, read 
> 134.c(3) of the 2005 penal code.

Right. If you want to know what typo I'm referencing, see revision 8762 of 
the HTML standard.

Snapshot specs don't help with this. They're too infrequent. What you need 
is a full history of the specification. That's what we offer with the 
WHATWG specs, in quite a number of forms.


> >> There are plenty of good reasons to reference a snapshot. For 
> >> example, if document A says “As defined in section x.y.z of R”, you 
> >> don’t want to risk the section number changing.
> > 
> > What kind of document would reasonably say that? If it's a spec, and R 
> > changes, then you should change your reference.
> 
> Not everyone changes everything all the time. Yes, at the next 
> opportunity to revise the containing document, one can update what you 
> point to.  That’s no excuse for confusing or misleading readers in the 
> meantime.

Pointing to a known-bad version of the spec is the confusing and misleadng 
behaviour in this scenario.

I'm sorry but if you can't keep your spec updated when what it relies on 
changes then you should not be in the business of writing specs.

It's just like with software. If you ship software with libpng, and the 
libpng authors find a security bug, you have to ship an update. If you 
ship software packages that include bash, and a security reseacher find a 
security bug in bash, you have to ship updates.

In the spec world, it's not about fixing security bugs, it's about keeping 
track of how other specs evolve.

You don't leave your spec permanently damaged (referencing a know-bad old 
copy of a spec) just because on some rare occasions the underlying spec 
has changed so much that it literally makes no sense to implement your 
spec as written any more. It's not like the implementors will want to 
implement the old spec you're pointing at. They're going to have to figure 
out how your spec works in the new world with the updated underlying spec 
whether you are pointing at it explicitly or not.


> > It's really important to make sure you're working directly with 
> > whoever is responsible for the documents you reference, too, so that 
> > you don't fall foul of Conway's law or worse.
> 
> People finish documents and at best put them on one side for a while.  
> Expecting everyone to keep editing constantly because you are editing 
> something they reference is expecting too much.

It's not too much. It's the bare minimum. If you can't keep your spec 
updated and maintained, get out of the spec business.


> >> (I think the idea that every spec. should necessarily be in constant 
> >> flux (and written in pseudo-Basic) is also damaging to the web’s 
> >> health, by the way. It’s not the best approach for everything. But 
> >> that is a separate topic.)
> > 
> > I think the reverse, as discussed in my earlier e-mail, where I put 
> > forth all the reasoning for that position. I also don't think it's a 
> > separate topic. I think it's the crux of the matter.
> 
> There is a reasonable balance between stability and revision, and where 
> that is can depend a lot on the content and nature of the specification.

Stability and revision are much more orthogonal than you imply. A platform 
can be remarkably stable while its specification is still being written. A 
platform can be in remarkable flux while the specification is unchanging. 
For example, some core aspects of HTML haven't changed since the mid 90s, 
but in that time we've literally rewritten the spec from scratch. 
Similarly, in the past couple of decades URLs have been in flux, despite 
the specs not changing in any substantial sense until recently.


> > Having the title be the same as the URL standard's would encourage you 
> > to reference this stale copy instead of the standard, and thus would 
> > itself be damaging to the Web's health.
> 
> Your inability to imagine good reasons does not mean they don’t exist.

I've asked many people over many years, including yourself, for reasons. 
No valid ones have been given other than the two I listed in the e-mail I 
cite above. Many bogus ones have been given, I discussed three in that 
same e-mail in footnote 1. There have been other bogus reasons given, e.g. 
"our organisation's authors have to refer a fixed version because we don't 
want to update all our software yet". That particular one is bogus because 
it implies that the software has an exact implementation of the fixed 
version of the spec in question, which is never true. That argument 
confuses a specification for implementation documentation.


> If you want the title changed to suit other people’s purposes, then they 
> get to choose the title. One could hope that they do a better job than 
> you, but why open that Pandora’s box? You have opened the door to 
> editing, which I would have thought you don’t want.

I'm not sure what you're saying here.


> You are *asking* for a fork, either by asking for change of title, or by 
> inventing an unacceptable title that forces a document copy. Why?

I've no idea how you go from my saying "forking is one of the worst things 
that could happen to a spec, publishing multiple versions of a spec is 
literally the anthesis of the entire point of writing standards", to "you 
are asking for a fork".

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