W3C home > Mailing lists > Public > public-w3process@w3.org > October 2014

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

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 7 Oct 2014 22:18:45 +0000 (UTC)
To: "David (Standards) Singer" <singer@apple.com>
cc: public-w3process <public-w3process@w3.org>
Message-ID: <alpine.DEB.2.00.1410072144530.12123@ps20323.dreamhostps.com>
On Tue, 7 Oct 2014, David (Standards) Singer wrote:
> On Oct 7, 2014, at 10:25 , Ian Hickson <ian@hixie.ch> wrote:
> > 
> > The problem is that having a snapshot doesn't do anything to safeguard 
> > people from arbitrary changes by unaccountable people.
> 
> It certainly does.
> 
> * I claim to have tried to implement version X of that spec.; you can 
> ask me to update to a later version, but you can only expect that I 
> conform to that version. I make no claim about provisions in later 
> versions.
>
> * The syntax element X is formatted exactly as defined for Y in version 
> Q of this specification. (This safeguards from the unaccountable 
> updating the name of Y in later versions, as previously noted).

Can you point me to an actual statement equivalent to either of the above 
two that is actually accurate?

I hear people suggest that this kind of thing happens all the time, but 
the only time I hear such statements is from marketing folk who are trying 
to sell their product, not trying to make any real claim as to the exact 
version being implemented. (This is best demonstrated by the many 
marketing statements made about "HTML5", which has been used to refer to 
everything from SVG to CSS, let alone any specific revision of a specific 
specification.)


> * You are given a patent grant from the following companies for their 
> applicable IPR under the following terms, for all IPR essential to 
> vetsion R of this specification.

Right. Patent lawyers. That's what the URL spec snapshot exists for.

You don't ever have to reference that document from another spec, though.


> I would prefer that the w3c specification do what you and others have 
> asked, and that is reference a precise point in the development of the 
> URL specification in the WhatWG

I'm not sure what you mean by "the w3c specification" here, but in any 
case, I am not asking that any spec reference "a precise point" in any 
other spec. Specs should reference the latest version of other specs. I 
feel I've made this point multiple times on this thread at this point, so 
if I haven't made it clearly enough by now, I should let others try to 
make that point instead.


> but I am not going to agree to that when the referenced specification 
> and the living specification have different titles

Great! That's *exactly the effect that the title is supposed to have*.


> I do not intend to ask my company for an FSA on a document with a 
> pejorative title

It doesn't have a pejorative title.


> and I would recommend the W3C fork rather than refer to a document with 
> a pejorative title. Why you are allowing your desire to be insulting to 
> trump these other considerations is, well, at least strange.

You've lost me again.


> >> Look, the ideal way to reference a specific version of a document is 
> >> to quote its revision in the repository.
> > 
> > Reference for what purpose?
> 
> When the referer (hint, maybe someone other than you) wants to refer to 
> a specific version of the document.

Yes, but for what purpose?


> You seem to think that I feel that ‘latest revision’ references are out 
> of place. 

I'm not sure what you mean. I'm saying that that is the only reference 
that should exist.


> Far from it; even ISO, that you despise

I'm not sure what makes you think I despise ISO. I know very little about 
ISO and certainly have no strong feelings towards it one way or the other.


> > For the purpose of implementors, that's not a good way to reference 
> > another spec at all, since you have to reference the latest fixes, not 
> > some arbirary earlier fixed point.
> 
> No, I don’t *have* to.  I might *choose* to.

What I'm saying is that IMHO it is a bad idea (leads to less 
interoperability) for a spec to refer to a specific version of another 
spec rather than the latest version.


> Don’t tell me what I *have* to do with my life.

This whole thread is about people trying to tell other people what to do. 
You want me to do something. I want you to do something, and not do 
another thing.


> If I think that the specification got royally messed up by a change in 
> version X+1, I might well choose to say “I do up to version X, no more.”

If the specification got messed up to the point where you, an implementor, 
want to no longer follow it, then fork it, and point to the new fork. It's 
highly unlikely that a spec will ever go through a single point where it 
is perfect. There'll still be bugs to fix, even if the original 
maintainers have gone off the rails and started making their version 
crazy. Being able to do this is the entire reason we've been asking for 
the W3C to use open licenses like the WHATWG, by the way.


> > For the purposes of the CG FSA, that's not a good way to reference the 
> > spec source either, since the contract refers to a fixed page.
> 
> Yes, I am assuming that by referencing a specific repository revision 
> the result is an unchanging text.

I mean the legal text of the FSA says that the W3C will identify the 
specification, and the W3C mechanism for this right now is a URL. In 
principle, if you can get a judge to accept a git revision ID as 
meaningful, then sure.


> >> So which is it?  Intentionally pejorative and insulting, or not?
> > 
> > It's intentionally pejorative, it's certainly not intentionally 
> > insulting. I've no idea who it would insult.
> > 
> > (It is pejorative because it "expresses disapproval", specifically of 
> > referencing the spec for implementor purposes. It's not pejorative in 
> > the sense of expressing contempt.)
> 
> Telling people you disapprove of them is insulting. Doing it in a 
> document that purports to be a technical standard is out of place.

The document itself doesn't say anything of the sort.

You said "It’s important that the snapshot be both semantically linked and 
physically linked to the succession of documents it is part of". I said 
that wasn't important. You said the view that it wasn't important was "a 
very narrow and intentionally pejorative view". It is, sure -- it 
disapproves of linking in this way, for the specific reason that I think 
it makes it more likely for implementors to refer to outdated text and 
thus result in interoperability problems. This isn't academic, we see this 
*all the time* with drafts on the TR/ page. People end up looking at 
ancient drafts full of known bugs fixed in newer versions. Thus why I 
think it's important that it be crystal clear to most readers of snapshots 
that those aren't appropriate for them.


In any case. I understand that your viewpoint is different than mine. I 
think I've explained why I disagree. I don't feel that you're 
understanding my arguments. I have no idea how else to express them, 
though. I also don't really understand where you're coming from, because 
(as e.g. at the top of this e-mail) it seems to me that your arguments are 
based on something that doesn't match what I see in reality. I don't know 
how to make progress here.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 7 October 2014 22:19:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:35:12 UTC