Re: WHATWG/W3C collaboration proposal

On 11/25/2014 02:07 PM, Domenic Denicola wrote:
>> I disagree (see below)
>
> I don't understand what you disagree with, even after reading the
> below. You quote your blog post:
>
>>> In particular, they are interested in evidence of wide review,
>>> evidence that issues have been addressed, evidence that there are
>>> implementations, and the IPR commitments that are captured along
>>> the way.
>
> In what ways is achieving these incompatible with the principle I
> stated, or with the examples I gave of how to satisfy it? Most of my
> concerns were about the snapshot document itself, whereas the things
> you mention are about process, issue tracking, testing,
> implementation reports, IPR submission forms... They seem unrelated.

In my experience process and results are intertwingled.  If you forgive 
me, I'll give a lengthy answer which describes a process that would work 
as you describe, why it is not often followed, and a process that more 
closely match how specs are currently written, and what the implications 
are for snapshots.

But before I do, my basic point is that cowboy spec development (a.k.a 
Commit-Then-Review) and discouraging stable snapshots is counter-productive.

For the longer answer, I'll start by introducing two terms from the 
Apache Glossary[1]: Review-Then-Commit (RTC) and Commit-Then-Review (CTR).

In projects employing RTC, *NOTHING* goes into the product (in this case 
a spec) until it has been throughly reviewed.  As applied here, that 
would mean that *NOTHING* would go into a spec until there was evidence 
of wide review, evidence that issues have been addressed, evidence that 
there are implementations, and evidence of the necessary IPR commitments.

Furthermore, in such projects, if an issue is identified, the 
problematic part of the work is promptly backed out, and not 
reintroduced until the issue is resolved.

In such an environment, it is a true statement that static snapshots are 
of little value as the latest version is always better.

I will also state that projects that follow RTC are rare.  That's 
because such a process intentionally slows things down.  Generally, only 
mature, stable, and widely deployed projects follow this process.  In 
W3C terms, think "errata".

Much, *much*, MUCH more common is CTR.  What this means is that a 
specification at any time may have a delightful mix of stable and proven 
bits as well as flights of fancy, items that are unproven and unstable, 
or were outright rejected by implementers.  This is the part that you 
left out.

This is not a bad thing.  In fact, it generally is necessary in order to 
make rapid progress.  But it does mean that depending on what you are 
looking for, the latest and "greatest" isn't always better than the 
trustworthy and proven version that was published last month or even 
last year.

In fact, there are known ways to compensate for this.  Such ways 
generally involve the creation of a stabilizing branch and removing 
features that aren't quite ready for prime time in that branch.  Such 
efforts are short duration, and produce a reference-able snapshot.

Note that such a snapshot is not merely for IPR purposes.  It exists to 
give spec writers the freedom and flexibility to explore new areas.  And 
consumers of the spec confidence in what they are reading.

I'll also note that it is the nature of web standards that once a 
standard is widely implemented -- or more importantly, there exist a 
significant corpus of content deployed that depends on that standard -- 
that "mulligans" or "do-over" opportunities are exceedingly rare.

What this means in practice is that suitably prepared Recommendations 
are rarely "stale"; and as long as errata is promptly prepared, they 
remain proven and valuable.  Newer versions, as they become available, 
simply contain more features.

  - - -

Now lets apply this to URL.  The concept of a URL is clearly a 
foundational concept of the web.  It also is messy, there also are many 
parts over which there isn't agreement (hello "file:"!).  It is by no 
means "done".  That being said, I believe there would be value in 
stabilizing the parts that can be stabilized in 2015 and putting out a 
W3C Recommendation containing only those parts.  I hope I can get the 
WebApps Working Group to agree on this.

In practice, doing so requires more work, and I believe I've 
demonstrated that I'm fully prepared to do that work.

And if people find value in that work (and trust me, there are many that 
do), I want to make that work as useful, friendly, and appetizing as 
possible.  And that means, among other things, stylesheets.

And furthermore, I don't plan to disappear after this work is done, nor 
say "not my job" to the parts that won't be stable in 2015.

I'm also introducing concepts along the way that I know you personally 
agree with: a reference implementation and test-first development.  I 
believe that such things will ultimately lay the foundation for a 
version of the spec under which "RTC" is possible, and new work is done 
in separate specifications.

- Sam Ruby

[1] http://www.apache.org/foundation/glossary.html

Received on Tuesday, 25 November 2014 21:47:50 UTC