RE: Option 3

Jonas wrote:
" Please do"

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. 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. 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." 
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. The more competing and incompatable specs there are the narrower the range of acceptability of specific utterances. 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.
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, hence clogging all available storage space, leaving no room for the utterances that those specs seek to enable. 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.
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"
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.
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. 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. 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. 
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.
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. 
There! Wasn't that fun?
cheers
David

________________________________________
From: Jonas Sicking [jonas@sicking.cc]
Sent: Tuesday, March 22, 2011 7:09 PM
To: Dailey, David P.
Cc: Ian Hickson; public-html@w3.org; PSIG
Subject: Re: Option 3
On Tue, Mar 22, 2011 at 3:39 PM, Dailey, David P. <david.dailey@sru.edu> wrote:
> On Tuesday Mar 22, Ian Hickson wrote:
>
> "If anything, fear of spec forking is an indicator of a lack of confidence in technical ability."
>
> Well, I'm not so sure about your foray here into diagnosing the source of one's fears. There are lots of other reasons I can postulate, and it might be worth doing an inventory of possible reasons for fearing spec forking. I can enumerate half a dozen without so much as the blink of a frog's eye, and none would necessitate postulating technical insecurity.
Please do.
/ Jonas


________________________________________
From: public-html-request@w3.org [public-html-request@w3.org] On Behalf Of Dailey, David P. [david.dailey@sru.edu]
Sent: Tuesday, March 22, 2011 6:39 PM
To: Ian Hickson
Cc: public-html@w3.org; PSIG
Subject: RE: Option 3

On Tuesday Mar 22, Ian Hickson wrote:

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

Well, I'm not so sure about your foray here into diagnosing the source of one's fears. There are lots of other reasons I can postulate, and it might be worth doing an inventory of possible reasons for fearing spec forking. I can enumerate half a dozen without so much as the blink of a frog's eye, and none would necessitate postulating technical insecurity.

I've noticed a fear that some seem to have about the fear of "license proliferation." Would your explanation of motives for fearing such proliferation hold here as well. Why not have new licenses for new specs?

Imagine a situation in which specs and licenses are invented numerously, concurrently, pseudo-randomly and in parallel, such that there is a many-to-many mapping between specs and licenses and some sort of Darwinian economics to determine the survivors. An oracle might be needed to pick from all the possibilities.

cheers
David





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

On Tue, 22 Mar 2011, Dailey, David P. wrote:
>
> When these issues were discussed in 2009, I was of the opinion [1], as I
> gather Larry Rosen has said that the consensus of the Working Group was
> that forking of the spec was not desirable.

This is incorrect. It is possibly the majority opinion of the AC
representatives of company members of the W3C that forking should not be
allowed, but it is not the consensus opinion of the HTML working group. In
fact, two of the use cases the working group presented to the W3C are
explicitly about forking. A solution that disallows forking wouldn't be
one that addresses the requests of the group.

(It would also be pointless, since any solution that disallows forking is
already less permissive than what we already have as the spec's license,
and would therefore not change anything.)


> " An organization or individual modifies the content of the spec in ways
> that intentionally misrepresent its content and that mislead others as a
> result. We do not, I think, want to encourage prosecution against the
> well-meaning author of a book who misunderstands the specification, but
> rather against those who might seek to perpetuate coding practices
> contrary to the spec which might, for example, favor one browser
> implementation over another."
>
> It is specifically that, I think that would constitute a fork.
>
> When two competing specifications for the same thing exist, it seems
> that a "standard" no longer exists.

Competing standards are not a bad thing. On the contrary, they ensure that
it is technical superiority, and not fiat, that continue to be used to
determine the organisation that has the authority to lead the Web.

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

Note that nothing stops someone from doing what you describe (modulo the
intentional misrepresentation). It is essentially how HTML5 started in the
first place, in fact, without any violation of copyright (we started from
scratch). I just want the next person who disagrees with the current path
to be able to do so without having to duplicate the last 7 years of work.

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

Received on Wednesday, 23 March 2011 02:43:41 UTC