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

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:
>> >>
>> >> At the other end of the scale, at the 'living spec' end, what
>> >> safeguards are there to prevent a single vendor setting the agenda
>> >> with the features it has in the pipeline?
>> >
>> > They're all always trying to do that. That's what competition is
>> > about. This happens regardless of the spec (indeed, it happens even
>> > without specs). It's not a problem specific to the "living standard"
>> > model.
>>
>> But with a versioned spec there is a finite boundary for a particular
>> version, and while a single vendor may still dominate there's only going
>> to be room for features A, B and C. With a "living standard" it's
>> open-ended, a single vendor can continually influence the trajectory by
>> proposing features D, E, F...
>
> Well sure, but in the time that the "living standard" would have those six
> features, the versioned spec would have had two versions each with three
> features, right? So the effect seems identical to me.

Not quite identical. Implementers are able to work against the first
version, rather than having to play catch-up in real time.

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

 At any particular
> time, a useful spec is being dominated by whatever the most innovating
> user agent is.

I'm not sure about that, seems to me the utility of a spec comes more
from common ground rather than unilateral innovation. Think
engineering - if you're making screws, you mostly need to think about
today's screwdriver/thread specs rather than tomorrow's.

Whether we just have one document that's continually
> updated or whether we such a document but describe as unstable and publish
> the occasional snapshot that we stop updating and describe as something
> more mature seems to be orthogonal to market forces.

I'm beginning to wonder what you see as the purpose of specifications.

As I see it, by designing to a (good) stable specification, you can
offer the guarantee of interoperability of your system with other
systems designed to the same spec.


If I was writing a Web agent (which incidentally I am, though it's
only tangentially in this domain) I'd prefer to design it against
fixed requirements, so I knew anything I implemented today will work
tomorrow. 011 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:
>> >>
>> >> At the other end of the scale, at the 'living spec' end, what
>> >> safeguards are there to prevent a single vendor setting the agenda
>> >> with the features it has in the pipeline?
>> >
>> > They're all always trying to do that. That's what competition is
>> > about. This happens regardless of the spec (indeed, it happens even
>> > without specs). It's not a problem specific to the "living standard"
>> > model.
>>
>> But with a versioned spec there is a finite boundary for a particular
>> version, and while a single vendor may still dominate there's only going
>> to be room for features A, B and C. With a "living standard" it's
>> open-ended, a single vendor can continually influence the trajectory by
>> proposing features D, E, F...
>
> Well sure, but in the time that the "living standard" would have those six
> features, the versioned spec would have had two versions each with three
> features, right? So the effect seems identical to me.

Not quite identical. Implementers are able to work against the first
version, rather than having to play catch-up in real time.

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

 At any particular
> time, a useful spec is being dominated by whatever the most innovating
> user agent is.

I'm not sure about that, seems to me the utility of a spec comes more
from common ground rather than unilateral innovation. Think
engineering - if you're making screws, you mostly need to think about
today's screwdriver/thread specs rather than tomorrow's.

Whether we just have one document that's continually
> updated or whether we such a document but describe as unstable and publish
> the occasional snapshot that we stop updating and describe as something
> more mature seems to be orthogonal to market forces.

I'm beginning to wonder what you see as the purpose of specifications.

As I see it, by designing to a (good) stable specification, you can
offer the guarantee of interoperability of your system with other
systems designed to the same 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.

While the past situation may have been far from ideal, the HTML5
effort seems to addressed many of the systematic problems. It is
allowing space for innovation (I'll overlook the distributed
extensibility issue here :) while paving the cowpaths. It's helping
level playing field for tool builders and publishers.

On the other hand, a "living" spec would be a significant optimisation
in favour of a monopoly/oligopoly kind of market. A big step in the
opposite direction. That strikes me as potentially harmful for the Web
at large.

Cheers,
Danny.

-- 
http://danny.ayers.name

Received on Friday, 25 February 2011 12:54:50 UTC