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 04:39:46 UTC