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

Actually I would like to make the strong case that the act of making a snapshot should not change the title.  The number plate on my car doesn’t change when I take a snapshot of it, after all.


The snapshot is a ’snapshot' because the URL and/or datestamp that references it is fixed.  The title should reflect the technical content of the document, no more, no less.  That does not change during evolution.  (One might even argue that not fiddling with the title comes under ‘respect’).

It’s important that the snapshot be both semantically linked and physically linked to the succession of documents it is part of.   Being able to explore antecedents is also possible.

We do that linking physically by ensuring that the document, in itself, has a link to that timeline, and most importantly, to the latest (usable) version.  “If you arrived here, you should be aware of the evolution, that is continuing, and a <later version> is/may-be available.”

We do that semantically by ensuring that the title is invariant and informative through the evolution; that helps people know that yes, what they have in their hands is the [dated | latest] version of that timeline. In the semantics we usually also provide a ‘version designator’.  That can be a date, repository revision, anything that helps the reader know that what is referenced is a specific revision.

Putting it all together, using fake names, directories, styles, and so on for a frozen reference:

Outside Reference:
WhatWG Stuff and Rhubarb, October 2014, http://whatwg.org/oct2014/rhubarb.html

Inside the document, title:

WhatWG Stuff and Rhubarb
October 2014


and inside that HTML
“The latest version of this is maintained at http://whatwg.org/bleedingedge/rhubarb.html; the history can be explored at http://what.org/history/rhubarb.html”

[there is also boilerplate that addresses the IPR flow, by documenting the CG, the policy, any FSA, etc.]



It should ALSO be possible to reference the document un-snapshotted, of course.  Both are useful in different circumstances.

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.  If you say “a froobotz as defined in R” you don’t want to reference a document in which the WG changed the name to “wokthang”.  And so on.  Intelligent readers will be able to work out that m.n.o in the latest document is the same as x.y.z in the referenced document, and what was called froobotz has become a wokthang.

(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.)


So, please can we have a snapshot that has the same title, has an FSA pass done on it, has a stable URL, an internal declaration that this is a snapshot and gives its revision marking, and uses the standard boilerplate so we can see the provenance, IPR grants, and so on?

Many thanks


On Oct 3, 2014, at 10:25 , Ian Hickson <ian@hixie.ch> wrote:

> 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.   `._.-(,_..'--(,_..'`-.;.'
> 

David Singer
Manager, Software Standards, Apple Inc.

Received on Monday, 6 October 2014 20:46:48 UTC