RE: Option 3

Ian, 
I think you missed the basic point I was making. I am not arguing here about whether or not it is good to allow spec forking. I'm arguing against the premise that all who would argue against it must be technically naive, which was the claim you seemed to have made in stating

"If anything, fear of spec forking is an indicator of a lack of confidence in technical ability."

It seemed rather like claiming that anyone who disagrees must be naive. That, to me, seems probably just as silly as some of the arguments I made seem to you. Yesterday, after recalling some of the arguments of two years ago, I am reminded of some of the good reasons for spec forking; I just see no reason to conclude that all disagreement stems from being daft. What end does that sort of argument serve? 

David
________________________________________
From: Ian Hickson [ian@hixie.ch]
Sent: Wednesday, March 23, 2011 12:39 AM
To: Dailey, David P.
Cc: public-html@w3.org; PSIG
Subject: RE: Option 3

On Tue, 22 Mar 2011, Dailey, David P. wrote:
>
> Oh goodie! An invitation to expound!
>
> a) Specifications for expressive languages like HTML are sort of like
> grammars. They sort utterances into piles: acceptable / unacceptable.

That's a secondary role that they can play, but it is by no means the only
role or even the most important one.


> Likewise IP regimens (licenses, legal codes, intellectual property
> systems) are like grammars sorting our uses of utterances or grammars
> into piles: acceptable or not. We anticipate our grammars to change as
> our technologies and cultures change; likewise we expect our IP regimens
> to evolve.

I don't see the relevance of the IP analogy here, but as far as us
expecting technologies to evolve, I suspect we are all in agreement. The
problem is that sometimes groups disagree about how technologies should
evolve, and one such group should not have the power to prevent another
such group from evolving the language as they see fit. (This isn't
theoretical; the W3C tried to prevent HTML from evolving only a few years
ago, and the spec license prevented a direct fork.)


> In fact, without too much extrapolation from fact one can
> easily postulate that the faster grammars change, the harder pressed
> licenses are to change. And some of the very same folks (avowedly strong
> in "technical ability") who decry "license proliferation" seek to enable
> "spec proliferation."

Not sure what this means.


> b) The reason for having specs is to allow people to know which
> expressions will be acceptable across the variety of contexts in which
> those expressions might be expected to make sense.

That's one of a number of reasons for having specs; the main reason is to
have a common description of a technology in order to enable
interoperability amongst multiple independent implementations.


> The more competing and incompatable specs there are the narrower the
> range of acceptability of specific utterances.

Thu number of incompatible specs is irrelevant, only the number of *widely
used* specs is relevant. A thousand people could publish their own HTML
specs tomorrow, but it wouldn't make the slightest difference if nobody
paid any attention to them.


> Alternative specs sort the expressive languge into dialects.  I'm not
> saying that the technically omniscient oracle would necessarily advance
> such a view, but rather that the relationship between technical prowess
> and advocacy of such a view is not obvious.

No idea what this means.


> c) If we imagine that specifications mutate with some probability p in a
> given period of time, then over time the number of specifications, if
> left unchecked by certain constraints, will grow exponentially

There are plenty of constraints. First, only specifications that have
broad adoption are relevant, and generally for any one technology there
will never be more than one specification (or set of mutually-compatible
specifications).


> hence clogging all available storage space, leaving no room for the
> utterances that those specs seek to enable.

Are you serious? You're arguing against allowing people to fork because if
we allow people to fork we will fill all the disk space of the world up
with forks of the spec?

Even if we grant the premise (that exponential growth of specs would
outstrip the growth of storage space, itself a questionable conclusion),
the entire concept here is absurd. There are plenty of other copyrightable
works that allow forks, for instance all free software. Yet there is no
sign that we are going to end up using all disk space for free software.


> Granted, there are factors, such as human energy, that tend to govern
> the mutation of specs, and I suppose the premise of the mutagenic
> advocates is that the free market ultimately decides when it is time for
> specs to mutate. But in my hundred and eight years of "confident
> technical ability" I have known many who fear the clogging of our
> airwaves, nets and brainwaves with redundant mutatenic ideation, and
> some of those invented things like hydrogen bombs, so I don't think
> their technical prowess needs to be brought into question.

I am going to ignore this paragraph in the interests of our mutual
dignity.


> d) if browsers a, b, and c follow spec X and d, e, and f follow spec Y,
> we no longer have a "world wide web"

This can happen whether we allow forking or not. In fact, it happens even
without any specs at all, where different browsers implement features
differently (e.g. XMLHttpRequest before we specced it). Preventing spec
forking doesn't in any way prevent this from happening; if anything, it
makes it worse, because if the W3C finds itself not following reality (as
has happened several times), it prevents another group from doing the job
instead (or at least increases the cost of doing so).


> e) specs have a tendency to be dominated by loudest voices. A sort of
> feudal society of alternative languages dominated by tribal leaders is
> possible. Some, perhaps not even "lacking in technical ability" might
> prefer universal oversight so that what works in Alabama would also work
> in Tahiti, outrageous and idealistic as that might seem.

This appears to be the exact argument I described: fear that if we allow a
W3C spec to theoretically fork, the chosen "universal oversight" of the
W3C would be at risk because some fork would succeed in the market,
overshadowing the W3C's spec.


> f) to some extent writing specs represents a "lack of confidence in "
> someone's "technical ability" Namely the odd class of people known as
> authors, who actually speak the languages that our grammars seek to
> parse.

I disagree with the premise that writing technical specifications makes
any sort of statement or representation about the target audience of the
technology it describes.


> If they were all so eloquent as those who develop user agents, then we
> might all speak xml and the need for half of the discussion this WG has
> had since 2007 would be obviated. But I don't believe that the lack of
> confidence that is being discussed here is concern over naive users.

I don't understand what you're trying to get at here.


> No, in fact, it is quite easy for me to imagine technically very
> sophisticated people whose concern about user confusion would be
> heightened by a proliferation of specs.

A proliferation of widely-adopted mutually incompatible specs would be the
same as having many different technologies competing, e.g. having HTML,
XForms, XHTML, .NET, Flash, SVG, etc, all competing. Such a situation is
not a stable state, and would not last. Format wars are not uncommon, but
they are relatively short, precisely because it is not in anyone's long-
term interests.


> g) If the advocates of mutagenesis believe that all antagonists act out
> of fear and ignorance, then this, itself, could be grounds for concern
> by some who were not necessarily antagonists to begin with. Conceivably
> some of those might be quite confident in their technical abilities.

You're arguing that one should fear spec forking because the people who
think that we should be able to fork specs think that those who fear spec
forking lack confidence in their ability to remain authoritative in the
face of spec forking? If so, I take serious issue with the terminology,
but furthermore, I think that argument is unfounded at best and flat out
cyclical at worst.


> I'm not saying that these are the only reasons people might not like
> specs to fork, nor that I agree with any of these reasons, but the
> question posed is whether or not an informed, confidant and rational
> person might have reasons to fear spec forking.

To recap:
Point "a" does not seem to be an argument against forking specs. If
anything it seems like an argument in favour of forking.
Point "b"'s premise is false.
Point "c" is absurd.
Point "d" is a fear that browsers will follow different specs if we allow
forking. The premise that forking would be the cause of this problem is
unfounded.
Point "e" is the fear I spoke of.
Point "f" appears to be a concern over format wars, which are not an issue
of forking as they occur regardless.
Point "g" is unfounded.

I conclude that you are wrong that there are many valid reasons to fear
spec forking. The reasons you list do not generally stand up to close
scrutiny. Furthermore, the opaque and obtuse manner in which you have
chosen to make these points suggests that you know this to be the case.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Wednesday, 23 March 2011 11:12:53 UTC