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

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.

As to what the proposal is called, please do not focus on that.  We have 
encouraged everybody to make changes in the hopes that the results will 
attract a greater consensus.  If these changes achieve that, then we all 
benefit.

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

> Secondly: the @vendor--feature attribute
>
> Despite that it is referred to as "zero-edit", it informs us that HTML5
> has a @vendor--feature attribute. This attribute is only one month old
> - and, says Ian, might still change, see bug 9590. [1] The bug,
> reported by Maciej, as well informs that this feature earlier was known
> as  @_vendor-feature.
>
> The comments in bug 9590 informs us that @vendor--feature is not
> possible to comment out, as the following would be an invalid comment:
> <!--<p vendor--feature>-->. @Vendor--feature also clashes with
> @data--feature attribute.
>
> Since I myself for long worked - and thought - on a change proposal for
> ISSUE-41, it is embarrassing to learn that HTML5 already _had_ a vendor
> prefix feature. My CP tried to cater for that. As tries Rob Ennals' CP.
> I myself  wrote to this list in August and asked the vendors for more
> info. [2]  But didn't get any response, not even a pointer saying that
> they thought the issue to be solved.
>
> I was believing I was working on a case that the vendors were
> interested in. But experienced zero interest. Finally I understand why
> ...  But until now, I was thinking that the reason for the zero
> interest, was that the vendors of this group weren't interested in such
> prefixes anymore. Which seemed quite logical to think given the
> rhetoric from so many of them _against_ extensions.
>
> Should I have known about _vendor-* and vendor--* ? Did the co-chairs
> know, apart from Maciej?
>
> How could I have known?  It is impossible to spot "_vendor-feature" in
> the Commit-Watchers mailing list - though it probably exist there
> somewhere (?). (While "vendor--feature" was easy to find.) However bug
> 9590 hints that _vendor-feature dates back to just before April 25th.
> At any rate, _vendor-feature first time appeared in the current
> published Working Draft, of 24th of June. [3] A search in public-html
> for _vendor does not reveal anything either. Discussion in the whatwg
> list seems to be not more than a moth old.

Doesn't look impossible to me:

http://lists.whatwg.org/pipermail/commit-watchers-whatwg.org/2010/thread.html

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

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

> Unclear:
> 	What if Robert Ennals proposal is accepted? What will then happen to
> _vendor or vendor-- ? Will we then go for the vendor solution that Rob
> Ennals suggests in his proposal instead? Or will someone then perform a
> "free interpretation" of what Rob Ennals' proposal is about?

It seems to me that the proposals are orthogonal enough that we could 
conceivably decide to support all four possibilities: one or the other, 
both, or neither.

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

> [1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=9590
> [2] http://lists.w3.org/Archives/Public/public-html/2010Aug/0059
> [3]
> http://www.w3.org/TR/2010/WD-html5-20100624/infrastructure#extensibility
> [4] http://lists.w3.org/Archives/Public/public-html/2010Sep/0213

- Sam Ruby

Received on Thursday, 23 September 2010 23:51:34 UTC