Re: ISSUE-41: Decentralized-extensibility - Straw Poll for Objections

On 09/23/2010 08:45 PM, Leif Halvard Silli wrote:
> Sam Ruby, Thu, 23 Sep 2010 19:49:29 -0400:
>> On 09/23/2010 07:19 PM, Leif Halvard Silli wrote:
>>> Sam Ruby, Thu, 23 Sep 2010 14:12:51 -0400:
>>>> The poll is available here, and it will run through Wednesday,
>>>> October 7th(*):
>>>>
>>>> http://www.w3.org/2002/09/wbs/40318/issue-41-objection-poll/
>>>
>>> Co-Chairs and Mike,
>>>
>>> Reading the socalled "zero-edit" proposal ("heavy-edit" would have been
>>> more accurate names), I discovered info that we have not had in time.
>>
>> The only relevant question at this point is whether the poll should
>> be withdrawn, proposals updated, and then reissued.
>
> I suggest that it should be delayed, yes.
>
> ....
>>> Firstly: The proposal referred to as 'zero-edit', consequently speaks
>>> about Microddata as a "feature" (a feature of HTML), while whereas
>>> HTML5+RDFa is presented as "applicable specification"extension. Draw
>>> you own conclusions. Even if I would have agreed with that proposal,
>>> those comments would hinder me from adding any support.
>>
>> *shrug*  People sometimes believe strange things that are at odds
>> with reality.  Unless those words appear in the document someplace, I
>> don't think that is relevant.
>
> It appears in the document many places:

Feel free to object to it.

> http://lists.whatwg.org/pipermail/commit-watchers-whatwg.org/2010/thread.html
>
> That commit is about "vendor--". I complained that it is impossible to
> find "_vendor-". (I had already found "vendor--".) I'm interested if
> you find _vendor.

I continue to see _vendor- on that page.

$ curl -s 
http://lists.whatwg.org/pipermail/commit-watchers-whatwg.org/2010/thread.html 
| grep _vendor- | wc -l
1

>>> Conclusions
>>>
>>> Irrational:
>>> 	The so called zero change proposers have, in parallel with their work
>>> on the so called zero change proposal, worked on an extension mechanism
>>> for vendors! This, in my mind, undermines the very point that the zero
>>> change proposers want to make. (They also claim it to be important that
>>> extension happens within the standard process framework -  however, the
>>> way _vendor/vendor-- has gotten into the spec, doesn't actually make me
>>> trust that view.)
>>
>> To the contrary, attempting to find something that addresses the very
>> use cases that you were pursuing in an attempt to garner wider
>> support is highly rational.
>
> To say that the zero-edit CP authors have worked on "vendor--feature",
> is colorful language on my part. It is Ian who is the editor.
>
> The issue is that we have tried to cater for that problem. Wasting
> resources on that issue, without being informed about a similar
> parallel effort: Clearly the main issue that the supporters of ISSUE-41
> have wanted to support is _not_ vendor prefixes. (And btw, my own CP
> placed vendor prefixes in no-namespace- so it was not far from the same
> thing as _vendor-feature.)

Can you explain how delaying would address this?

>>> Uncollegial:
>>> 	More seriously, the other Change Proposal authors (including myself)
>>> have not been informed about this, and thus have been prevented from
>>> responding - positively or negatively - to this vendor prefix feature.
>>> E.g. the _vendor-feature solution has many likeness with my own change
>>> proposal, since my entire proposal was based on prefixes beginning with
>>> the underscore letter. I would have liked to know this as I worked and
>>> thought about my own proposal.
>>
>> The question on the table is not whether this person or that group is
>> or are bad people, the question on the table is which proposal will
>> garner the least objections.
>
> And that is why polls should be arranged in a way which do not attract
> attention to side issues. Lack of objections should come as result of
> real lack of objections. Not because the process is so tiresome and
> unpredictable that it isn't any inspiring to participate.
>
> There are two issues: information about _vendor/vendor--. The other
> issue is time to study the zero-edit proposal.

We have current allowed for two weeks.  Can you state how much time you 
feel would be necessary to study this proposal?

>>> Late:
>>> 	The change proposals have existed for months. The zero-edit proposal
>>> has existed for 4 days. [4] Had it been presented to the group in due
>>> course, then probably much of this would have been solved in time.
>>
>> The length of time is irrelevant.
>
> Not to me as a Change Proposal author. It is highly relevant to know
> what the other proposals are about and so.

Can you state how much time you feel would be necessary to study this 
proposal?

>>   Please record any concrete
>> objections you might have to one or both proposals as they exist now
>> in the survey.
>>
>>> PS: I am really happy that Maciej suggest new bugs should go to this
>>> list. That should have happened long ago.
>>
>> Agreed.
>
> Thus you admit that length of time is relevant. Because I suppose we
> both want Maciej's proposal so that so that you can stay informed.

I don't see how you come to that conclusion, but at the present time I 
believe that two weeks is enough to study both proposals, and I am 
curious how much time you feel you need.

> Had I been aware of bug 9590, then I would also have been aware of
> _vendor and vendor--. I have read Rob Ennals change proposal many
> times. THat has helped me understand it.  Likewise, I had read the
> zero-edit proposal early enough, then a) I would have helped - or hurt
> - my own CP, b) I would not have sent this letter to you today.

- Sam Ruby

Received on Friday, 24 September 2010 02:29:17 UTC