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

OK, you make no sense and seem to insist on a fork.

sorry for wasting people’s time on this group.

On Oct 7, 2014, at 15:18 , Ian Hickson <ian@hixie.ch> wrote:

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

David Singer
Manager, Software Standards, Apple Inc.

Received on Tuesday, 7 October 2014 22:46:59 UTC