Re: Option 3

Point d) appears to be the 'nuts and bolts' concern. However, something perhaps obvious but just dawning on me: I have interpreted the forking of a spec in this discussion thread to be Spec 2 becoming significantly different from Spec 1 from which it evolved and Spec 2 existing at the same time as Spec 1.

But are we just talking about the fork being a development arm of Spec 1 that will eventually become Spec 1? If so, as with the normal evolution of anything, new parts will experimentally be implemented and available before there is consensus and inclusion of those parts in the official spec. Any way permissions are worded for referencing or using Spec 1 should allow for this.

-Doug Jones

On 2011 Mar 22, at 22:41, Dailey, David P. wrote:

> 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 14:16:05 UTC