Re: HTML.next and Rechartering

On Sep 12, 2011, at 20:35 , Aryeh Gregor wrote:
> (I don't know if this is off-topic for public-html.  If it is, someone
> please say so and I'll stop.)

Since it concerns more than just the HTML WG, and since there seems to be interest in evolving the process expressed from multiple sides, might it be useful for the AB to open a public-process mailing list for such matters?

> But there is no final specification.  Even with versioned specs, any
> spec of importance will be maintained in future versions.  HTML5 will
> be a snapshot, for instance, while work will presumably continue in
> HTML6.  Then eventually that will be snapshotted, and work will
> presumably continue in HTML7.  And so on.  (Assuming no changes to
> Process.)  Likewise we have DOM4 as the new version of DOM 3 Core,
> which will presumably be followed by DOM5.  And so on.

Actually, in some cases there may be final specifications. I wouldn't be shocked if DOM4 were the last DOM. At some point we know what we need, we describe and test it in a way that is sufficient for interoperability, and call it a day (or a decade, as it were). API additions are likely to be orthogonal to the DOM.

But that's not the point. Nothing in this discussion hinges usefully on the fact that a specification may be final or not. What we collectively need boils down to satisfying two aspects:

    • a specification that is continuously improved in a tight feedback loop with the reality of implementation; and
    • at regular intervals, anchors of stability in the above flow that have specific characteristics.

Aside from the observation that we might wish to base an evolution of the process on something like git-flow, I think that the point of contention is the set of characteristics that these anchors must have.

In my experience patent people like there to be some (attempted) grounding in reality for RF licences that constrain what may be licensed under some form of reality principle so as to avoid a group cramming features into a draft in order to weaken some given intellectual property without anyone really intending to implement the whole thing. That's why the RF licence can be limited to bona fide implementations of the REC. Requiring actual implementations is far from ideal in many ways, but it was deemed an acceptable constraint. Note that the RF licence "may be suspended with respect to any licensee when licensor is sued by licensee for infringement of claims essential to implement *any* W3C Recommendation" (my emphasis). This makes RECs quite powerful in that they have IP implications even for non-participants. This naturally means that any form of snapshot with RF implications will require some form of patent review. I don't personally much care for patents, but if we want to get RF licences we need to strike a workable deal with the people who do.

Also please note that snapshots aren't used solely for the PP. Contracts often require something real to anchor off of. For this you need some form of version tagging that's considered stable, or even a stable branch if it's widely recognised to be trusted as such. Whether or not such contracts are daft is not really a question here — it's an extremely widespread practice that's unlikely to change inside even of a decade or two.

Finally please keep in mind that just because RECs have at times been meaningless in the past, they (or whatever they are replaced with) don't have to be in the future. We can sediment to REC only what's stable and tested. Also note that doing so in a timely manner can facilitated by smaller, modular specifications (just sayin').

> So whatever happens, companies will be making patent commitments on
> some kind of snapshot.  The snapshot will never be complete or final
> because the web will continue to evolve.  In many cases, the snapshot
> will be technically obsolete by the time it reaches REC.  Why does the
> snapshot used for patent commitments also have to be interoperably
> implemented?  This seems very bad, actually: it forces implementers to
> create their implementations with no patent protection.  Surely we
> want them to have patent protection *before* they begin
> implementation, if possible.

Snapshots based on interoperable implementations do not become obsolete simply because there is a more advanced version. Content that was valid with them still is, tools that produce such content are still valuable, and in a large set of cases applications that only consume content to that level are still very much useful.

It would be great to have patent protection before implementers get started, but of course that makes it difficult in turn to support a tight feedback loop between the spec and implementations. Currently there are two snapshot points at which an exclusion period starts: FPWD and LC (the latter only covering the feature delta from the previous exclusion period). Could a minimal-fix to the Process be to activate the RF licence at the end of these exclusion periods?

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Received on Tuesday, 13 September 2011 10:27:31 UTC