W3C home > Mailing lists > Public > public-html@w3.org > September 2010

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

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Fri, 24 Sep 2010 13:12:19 +0200
To: Sam Ruby <rubys@intertwingly.net>
Cc: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>, Michael Smith <mike@w3.org> (tm), Maciej Stachowiak <mjs@apple.com>, Paul Cotton <Paul.Cotton@microsoft.com>, HTML WG <public-html@w3.org>
Message-id: <20100924131219173399.4befe821@xn--mlform-iua.no>
Sam Ruby, Thu, 23 Sep 2010 22:28:42 -0400:
> 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.

"Unless those words appear in the document someplace"

We are supposed to give technically related response, but you suggest I 
use space in the poll to object to a political matter.

>> 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 
> | grep _vendor- | wc -l
> 1

I take that as a signal that you, like me, are unable to find the time 
when _vendor was inserted into the spec. (That _vendor since was 
changed to vendor-- is undisputed.)

>>>> 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?

3-4 weeks, in which time the change proposal authors can update their 
text further more, to see if they want to comment  the other proposals 
etc. The best would be to shoot up the vote with a month.

>>>> 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?

Those two weeks are for the voters. I think the CP authors should get 
3-4 weeks to see if they need to update their proposals. Thereafter, 
the poll can be restarted. I will also consider reactivating my own 

>>>> 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?

Authors needs at minimum 2 weeks, but 3-4 weeks is more realistic, to 
consider updates to the proposals. We need to have coherent change 
proposal which are clear alternatives to each others.
leif halvard silli
Received on Friday, 24 September 2010 11:12:51 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:05 UTC