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

On Oct 6, 2014, at 16:18 , Domenic Denicola <domenic@domenicdenicola.com> wrote:

>>> 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.
>> 
>> In theory, the problem above would be solved if browser vendors could 
>> say "our version X implements feature Y retrieved from commit ZZZZZ"
>> and if commit ZZZZZ was VERY easily reachable for people not used to 
>> our versioning systems. I see this as a workable compromise: no need 
>> to have snapshots, commits are snapshots, and your specs can remain 
>> living standards.
> 
> I want to interject here and say that we in the WHATWG absolutely support an effort like this. I suggested this to Ian a while ago for HTML, and he filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=26252. The case that motivated me and that he sympathized with was for implementers to be able to add comments to their code linking to specific commits that they implemented. That way when someone comes across the code later, they can be sure to find the spec text that the original coder used, without it having changed from under them. And they can compare it to the current spec to see what changes and fixes have been made!

yes, this is generally useful for understanding what people were reading when they did something.  I have no idea why we manually make snapshots when commit versions do exactly that. very cool.

> 
> Practically speaking, I am experimenting with this in the Streams Standard. The Living Standard is at https://streams.spec.whatwg.org/, but commit snapshots are auto-generated at https://streams.spec.whatwg.org/commit-snapshots/ with every push to GitHub. This isn't really ready yet (that's why I say experimenting); in particular it's missing appropriate out-of-dateness warnings on the commit snapshots (which will probably look and behave something like http://jsbin.com/mutefami/1/), and it also needs a way of getting a URL for the current commit (currently you have to navigate to them manually).

Cool.  I suggested something like this to a couple of other people, and am greatly encouraged that you are trying it out.  Keep us posted on what you learn.

> 
> But in any case, once I've successfully used Streams as the guinea-pig for this sort of process, I can see it being adopted in other WHATWG specs (including HTML, judging by bug 26252). So ... common ground!? Perhaps even progress?
> 

I like it as a direction. It automates a whole load of things which should not be manual, gives good visibility into history, future, and intent (of someon reading, as you say), and so on.

David Singer
Manager, Software Standards, Apple Inc.

Received on Tuesday, 7 October 2014 00:17:08 UTC