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

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.

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.

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. 

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

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.

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?

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.

PS: I am really happy that Maciej suggest new bugs should go to this 
list. That should have happened long ago.

[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
-- 
leif halvard silli

Received on Friday, 24 September 2010 00:20:05 UTC