Re: Please explain the role of the W3C in the continuing development of HTML

On 8/18/2011 6:40 AM, Danny Ayers wrote:
> On 18 August 2011 09:41, Ian Hickson<ian@hixie.ch>  wrote:
>> On Fri, 25 Feb 2011, Danny Ayers wrote:
>>> On 25 February 2011 09:45, Ian Hickson<ian@hixie.ch>  wrote:
>>>> On Fri, 25 Feb 2011, Danny Ayers wrote:
>>>>> On 25 February 2011 03:26, Ian Hickson<ian@hixie.ch>  wrote:
>>>>>> On Fri, 18 Feb 2011, Danny Ayers wrote:
>>>> The specs follow the market, not the other way around.
>>> For the most part I agree, but the specs must surely have some influence
>>> on the market - otherwise why bother?
>> Their influence is merely a matter of helping the browsers converge on an
>> interoperable set of details. If someone specs something the market
>> doesn't want, the spec isn't going anywhere.
> [snip]
>
> Yep, sure.
> And I would argue that convergence on a fixed point (e.g. a versioned
> spec) is easier that a moving target (e.g. a 'living' spec).

I would add to this discussion that we need to be mindful of where we 
are in the development cycle.

Certainly, in the early phases of development it does not yet make sense 
to converge to a fixed point.  We have now recognized that reality and 
have introduced Community Groups to facilitate specification development 
in areas of rapid innovation which are too early for standardization.

And I agree Danny, that as a spec matures and stabilizes, it is quite 
useful for the ecosystem to  converge to a fixed point - a versioned 
spec.  And to be sure, there will continue to be innovation beyond which 
would lead to the next version.

>
>>> Regarding market forces, under normal circumstances investors are likely
>>> to prefer designs which offer such guarantees. But if there isn't a
>>> stable spec, the only way you can make any such guarantees is by having
>>> direct influence over the direction of the specs. It's not hard to see
>>> where the big players are likely to position themselves in such a
>>> scenario. Far from being orthogonal to market forces, the "living"
>>> approach will encourage big vendors to further insert themselves into
>>> the loop - and it's a positive feedback loop.
>> This assumes an operational model that has never existed.
> True, I'm extrapolating from general observation and mixing in
> opinion. The nearest precedent I can think of for a mass-market
> 'living' spec is RSS, and that was a total mess that wound up being
> locked down in a fairly poor state, and partially superseded by Atom
> (which was developed using more traditional IETF processes).
>
> In the past,
>> when specs were not living documents but were instead fixed, the result
>> was that the specs became less and less related to reality, culminating in
>> the ultimate failure that were XHTML2 and XForms.
> That's confusing correlation with causation.
> While I agree that there's more likely to be a useful feedback loop in
> a 'living' spec, that doesn't negate the value of fixed versions.
> Things like XHTML2 lacked the benefits of agile processes, but that
> doesn't mean everything about traditional spec process is broken. One
> problem may be solved, but the door is wide open to others.
> Timestamped versions offer an anchor, without which the spec can drift
> out to sea.
>
> Moving to reliance on a 'living' spec has broad implications, most of
> which we can't predict.
>
> Cheers,
> Danny.
>

Received on Thursday, 18 August 2011 13:00:14 UTC