- From: Ian Hickson <ian@hixie.ch>
- Date: Wed, 23 Mar 2011 04:39:17 +0000 (UTC)
- To: "Dailey, David P." <david.dailey@sru.edu>
- cc: "public-html@w3.org" <public-html@w3.org>, PSIG <member-psig@w3.org>
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