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

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:

]]
* Authors can use the microdata feature (the item="" and itemprop="" 
attributes) to embed nested name-value pairs of data to be shared with 
other applications and sites.

Additionally, authors may use appropriate elements and attributes from 
other applicable specifications, such as HTML5+RDFa, to imbue their 
documents with specialized semantics.
[[

]]
with the Microdata feature, with HTML5+RDFa,
[[

]]
The HTML5+RDFa spec being worked on by this WG can address this use 
case, as can the Microdata feature.
[[

]]
with the Microdata feature, with HTML5+RDFa,
[[
 
>> Secondly: the @vendor--feature attribute

>> 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
  [...]
> Doesn't look impossible to me:
> 
> 
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.

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

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

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

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

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

Received on Friday, 24 September 2010 01:46:48 UTC