Re: WHATWG/W3C collaboration proposal

On 2014-11-25 13:47, Sam Ruby wrote:
>
>
> 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.

Instead of a stabilizing branch where separate work is done to get to 
it, couldn't non-stable, non-widely implemented sections be marked as 
one of the categories you mention above in the main document?  so a 
snapshot is automatic - it just removes the sections that aren't mature. 
(so no separate "stabilizing" work - it's part of the main spec - or at 
most pointing out where the labels aren't set correctly.  So new 
experimental stuff is clearly marked as new experimental stuff.)

>
> 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 Wednesday, 26 November 2014 01:06:11 UTC