RE: snapshots vs. living standards

I think this misses a key point of what the formal stages are for.  No one is saying people should not implement the latest drafts.  Obviously, they are being implemented and that is good.

I'm not a lawyer and don't want to make any statements about when patent obligations do or don't apply - what I'm doing below is repeating what is in the W3C patent policy.

WHATWG as far as I know has no explicit patent obligations.

W3C does have explicit patent obligations from all members of a WG for the output from that WG - so everyone in each WG for the whole specs.

That is a big difference and one that requires a difference in process.

If Members with large patent portfolios are committing to license patent claims, they need to be able to evaluate what those obligations are and they need to be able to opt out if they are not willing to make those licensing promises.

That can't be done practically if a spec changes every time the editor decides to change it.  Lawyers can't be sitting there reading all the WG emails and doing constant evaluations.

So there are fixed points where obligations happen after a time for lawyers to review.

One is at the official First Public Working Draft.  There is a period of time that for things in that draft an opt out can happen.  If you don't opt out, you're committed if it makes the final Rec.  Another crucial stage is Last Call.  For things added since First Public Working Draft, there is an opt out there.  Anything that could have licensing implications that change after Last Call means it has to go back to another Last Call for the new material to have an opt out period.  So obligations accrue as these stages are reached - if it makes it in the final Rec.

Finally, when the draft reaches Recommendation, the licensing commitments that were promised at the earlier stages come into effect for the parts that actually made it into the spec.

If people don't want those stages where review happen and where the copy being reviewed doesn't change, they probably aren't going to be getting patent licensing commitments from Members other than for their particular contributions.  (e.g. switch the model for Community Groups, not the current one for W3C WGs).

I think the options are to either change the patent policy and drop the commitment from all WG members for all the specs in that WG, or have these stages for review and exclusion.  But that doesn't mean there can't be a more effective way to point to the editor's draft or to change drafts themselves at formal stages to indicate when there have been later formal WG pubs.  The WG can also pump out a regular Working Draft every month if they want to.  There doesn't have to be a big gulf between editors draft and formal WG Working Draft in time.

I think this is a matter of there being a necessary cost if you want increased licensing.  If you don't care about the licensing, it can be simpler.  (but even there, in some industries and for some uses they're going to want to be able to take a snapshot and say that you have to do at least that.)

>-----Original Message-----
>From: Philippe Le Hegaret [mailto:plh@w3.org]
>Sent: Friday, March 02, 2012 10:28 AM
>To: public-w3process@w3.org
>Subject: snapshots vs living standards
>
>Hi All,
>
>I noticed the following post from Ian Hickson and thought it is relevant for this
>list. I'm copying the content here to facilitate the discussion.
>
>[[
>In a recent private discussion spawned from one on a W3C mailing list, I was
>defending the "living standard" model we use at the WHATWG for developing the
>HTML standard (where we just have a standard that we update more or less every
>day to make it better and better) as opposed to the "snapshot" model the W3C
>traditionally uses where one has a "draft" that nobody is supposed to implement,
>and when it's "ready", that draft is carved in stone and placed on a pedestal. The
>usual argument is something like "engineering depends on static definitions,
>because otherwise communication becomes unreliable". I wrote a lengthy reply. I
>include it below, in case anyone is interested.
>
>With a living standard, one cannot change things arbitrarily. The only possible
>changes are new features, changes to features that aren't implemented yet or
>that have only had experimental implementations, and changes to bring the
>specification even more in line with what is needed for reliable communication,
>as the argument above puts it (or "interoperability", as I would put it), i.e. fixing
>bugs in the spec.
>
>With a snapshot-based system, like the W3C TR/ page process, adding new
>features is done by creating a new version, so we'll ignore that, and experimental
>stuff is taken out before taking the snapshot, so we'll ignore that too. That leaves
>the fixing bugs.
>
>Now either one doesn't fix the bugs, or one does fix the bugs. If one fixes the
>bugs, then that means the spec is no more "static" than a living standard. And if
>one doesn't fix the bugs, then communication becomes unreliable.
>
>So IMHO, it's the snapshot-based system that's the one that leads to unreliable
>communications. Engineering doesn't depend on static definitions, it depends on
>accurate definitions. With a platform as complicated as the Web, we only get
>accurate definitions by fixing bugs when they are found, which inherently means
>that the definitions are not static.
>
>Note that we know this system works. HTML has been developed in a "living
>standard" model (called "working draft" and "editor's draft" by the W3C) for
>seven and a half years now. Interoperability on the Web has in that time become
>dramatically better than it ever was under the old "snapshot" system.
>
>Also, note that the snapshot system without applying fixes, which is the system
>that the W3C actually practices on the TR/ page (very few specs get errata
>applied, even fewer get substantial in-place corrections in any sort of timely
>manner), has demonstrably resulted in incorrect specs. HTML4 is the canonical
>example of this, where in practice that spec is woefully inaccurate and just poorly
>written, yet nothing was ever done about it, and the result was that if you wanted
>to write a browser or other implementation that "communicated reliably" with
>other HTML UAs, you had to explicitly violate the spec in numerous ways that
>were shared via the grapevine (the default value of the "media"
>attribute is the example I usually give of this).
>
>And also, note that having a static specification doesn't ensure that nothing will
>ever change. HTML is a stark example of this, where from
>HTML4 to the contemporary specification many things have changed radically.
>But you might say that's my fault, so look instead to XML:
>the specification has changed such that implementations of the original standard
>are no longer conforming to the current standard. In fact, XML is arguably
>developed in a kind of "living standard" approach now, despite officially using the
>snapshot model. Things change, especially in software. And that's ok!
>
>But it's incompatible with the snapshot model. Or at least, interoperability is
>made harder with the snapshot model.
>
></soapbox>
>
>Before commenting on this, please check to see if your argument is already
>refuted on the WHATWG FAQ: http://wiki.whatwg.org/wiki/FAQ ]]
>https://plus.google.com/107429617152575897589/posts/NZBJe6Jjt1f

>
>Philippe
>
>

Received on Saturday, 3 March 2012 00:13:03 UTC