On 8/18/2011 6:40 AM, Danny Ayers wrote:
On 18 August 2011 09:41, Ian Hickson<[email protected]> wrote:
On Fri, 25 Feb 2011, Danny Ayers wrote:
On 25 February 2011 09:45, Ian Hickson<[email protected]> wrote:
On Fri, 25 Feb 2011, Danny Ayers wrote:
On 25 February 2011 03:26, Ian Hickson<[email protected]> 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.
