Re: Formal Objection to One vendor, One Veto

Sam Ruby wrote:
> Shelley Powers wrote:
>> Sam Ruby wrote:
>>> Shelley Powers wrote:
>>>> I believe the process to register a formal objection is to send an 
>>>> email to this group, and label it as such. If there's another group 
>>>> I should contact, please let me know.
>>>
>>> I'll check into the process (and am copying Mike and Dan as they are 
>>> the W3C team contacts for this working group, but meanwhile three 
>>> things:
>>>
>>> 1) This Mailing list is described as a "Miscellaneous.  Mail-to-web 
>>> gateway" on http://lists.w3.org/.  My understanding is that its 
>>> primary purpose is to allow a public URI to be associated with an 
>>> email that is sent.  As a general rule, it is a great resource for 
>>> taking discussions "off-line" which may later need to be referred 
>>> to.  In any case, I have seen this email, and will take it seriously.
>>
>> Oops, then this is definitely the wrong place for this.
>>
>> I'll resend to the HTML WG list, then.
>
> Thanks!
>
>>> 2) The document in question is merely a Working Draft at this point 
>>> which means that it may be unstable and may not meet all of the 
>>> Working Group's needs at this point.  As such, a formal objection 
>>> seems a bit premature, but only by a little bit as it makes perfect 
>>> sense to me for Formal Objections to block advancement to Last Call.
>> I'm not sure how we can move to Last Call.
>>
>> Right now, we have no commitment one way or another from Microsoft on 
>> most aspects of HTML 5. According to Ian, Microsoft has the strongest 
>> veto of all. If it were to come in and just make a statement -- no 
>> we're not supporting Canvas, or MathML, or SVG, or any number of 
>> other elements--, just a statement of fact, then supposedly, *poof*, 
>> they're gone.
>>
>> Why call this HTML 5? We might as well call it the Sword of Damocles 
>> HTML and be done with it.
>>
>> As it is, we've already run into one vendor/one veto with the video 
>> element. Oh, and that's another one that MS has not made a commitment 
>> about.
>
> Getting Microsoft to actually review the document is something that is 
> clearly important.  By the way, and somewhat related: the working 
> group previously decided to include canvas, and did so over objections 
> by myself and Chris Wilson at the time:
>
> http://www.w3.org/html/wg/tracker/issues/15
>
> http://www.w3.org/2002/09/wbs/40318/req-gapi-canvas/results

Since Chris works for Microsoft, following what Ian has said, the Canvas 
element should be removed. To ensure consistent adherence to one 
vendor/one vote.


>
> The reason why I bring this up is that the group decided to include 
> canvas, so therefore any draft which does not include canvas could not 
> be considered as a candidate draft for Last Call... unless there was 
> another group decision which reversed the prior decision.
>
>>> 3) I need to think more about what it means to have a formal 
>>> objection to process as opposed to a result.  Formal objections to 
>>> results, like a document which contain features like video which do 
>>> not lead to interoperability due to a lack of specifying a common 
>>> royalty-free codec: that is something I can get my head around.  A 
>>> formal objection to removing Canvas (I chose Canvas as that is an 
>>> item that the working group previously voted on and decided to 
>>> include) in the unlikely event that Microsoft makes a statement that 
>>> they will never support such a feature -- that too, I can 
>>> understand.  But a Formal Objection to something that not only 
>>> hasn't happened, but may never happen -- that is something I need to 
>>> ponder on further and consult with others.
>>>
>> I understand I'm not following procedures. Sorry about that. But it 
>> doesn't lessen my concerns.
>>
>> Do we assume, then, that the one vendor/one veto rule only applies 
>> when a company specifically states it will not support something? 
>> Shouldn't it also apply when a company doesn't say whether they will 
>> or won't support one aspect of the document or not?
>>
>> If the purpose behind this one vendor/one veto approach is to ensure 
>> we no longer have what we had in the past, the inability to use all 
>> of the available web technology because of lack of support among one 
>> or more browsers, then unless the five vendor companies specifically 
>> state they will support each element, or concept, documented in HTML 
>> 5, we should immediately seek to remove it now--rather than wait 
>> until some later time when we finally have to corner each and ask, 
>> "Well, will you or won't you?"
>>
>> I focused on SVG, MathML, Canvas in the objection, but there's a more 
>> serious item that was brought up in my comments last night: the XML 
>> serialization of HTML 5. It is very much at risk, because we have no 
>> commitment from one company to support XHTML 5. And with one 
>> vendor/one vote, that means we can kiss it good-bye, too.
>>
>> We can't depend on anything now. Oh, a few scraps tossed us, some new 
>> goodies like client side storage. You know, to keep the kiddies 
>> entertained.
>>
>> I take things that people tell me as truth. Ian has stated one 
>> vendor/one vote. Not saying anything about canvas, SVG, XHTML, 
>> MathML, etc., is a vote. It's a vote saying, "No". Ignoring the great 
>> hulking elephant in the corner while professing to adhere to 
>> consistent procedures is not something I'm particularly good at.
>>
>> Sorry, Sam. I am new to this, and most likely not following proper 
>> procedures. But there is more than a hint of lack of consistency to 
>> the procedures followed with HTML 5, so in a way, I'm only following 
>> the course others have set.
>
> Don't worry too much about the process... you have a legitimate 
> concern, and we are here to help with the process.
>
> I am also not suggesting that Ian is lying.  In fact, I presume that 
> he is serious.  My point is that first and foremost that the situation 
> to which you are objecting is both hypothetical and not binding to the 
> Working Group.  As far as I am concerned, Ian can add or remove what 
> he wants to his draft, and should he remove canvas, any member of the 
> working group can produce another draft that restores it.  If this 
> were done, and both drafts were submitted for consideration, only the 
> latter would meet the basic requirements agreed to by the working group.
>
> Taking a quick peek at the charter of the group[1], removing XHTML 5 
> would also not meet requirements, which again means that we would have 
> to have a group decision to pursue a different path before we could 
> consider a draft which removes such.
>
> And, again, I'll note that group decisions can -- and have -- been 
> made without unanimity.  In particular, against the expressed opinion 
> of representatives from specific browser vendors, including Microsoft. 
> And, for that matter, myself.  But when a group decision is made, I 
> intend to support it.
>
>> Shelley
>
> - Sam Ruby
>
> [1] http://www.w3.org/2007/03/HTML-WG-charter
>

This is probably the better place to have this discussion, I'm already 
cluttering up the HTML WG too much.  To me, though, this highlights the 
real problem with HTML 5.

Ian comes in from the WhatWG side with his rules he applies to what will 
or won't be in the specification. But then there's a completely 
different set of rules on the W3C side, and the two are not compatible. 
Angry contention results, lots of back and forth, some of which occurs 
in the WhatWG group, some in the HTML WG and lots in Twitter and IRC.

So the HTML 5 document is really based on this hodge podge of 
inconsistent principles, erratically applied, typically based on what 
Ian says, except in the rare cases where there's enough noise to shout 
him down, and where the only thing we can count on is that we can't 
count on anything.

OK. Good to know I'm finally catching on.

Shelley

Received on Wednesday, 8 July 2009 13:33:37 UTC