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

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).

>> 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.

-- 
http://dannyayers.com

Received on Thursday, 18 August 2011 10:41:25 UTC