Re: Formal Objection to One vendor, One Veto

Lachlan Hunt wrote:
> Shelley Powers wrote:
>> 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.
>
> I think this is a mischaracterisation and over exaggeration of the 
> issue.  It's not quite as simple as you make it out to be, and I think 
> this is unnecessarily increasing the tension of the situation.

I have to disagree. I think it describes the issue rather neatly. The 
issue is explicitly one vendor/one vote. Implicitly, though, is the fact 
that "rules" are being applied to support decisions about what is or is 
not included in HTML 5, and these "rules" are applied both 
inconsistently and arbitrarily--including the rule supposedly of one 
vendor, one vote, which was specifically used with the video element.

As for increasing tension, when a situation is relatively harmonious, 
tension can disrupt. But when the environment is already angry, 
suspicious, distrustful, divisive, and derisive, as best describes the 
effort surrounding HTML 5, any increased tension is most likely 
unnoticeable. What's another drop in a flood.

>
> When a vendor objects to implementing something, that doesn't result 
> in the instant removal of the feature.  Rather, we need to seek ways 
> to resolve the situation and find some alternative that they will 
> implement.  When the requirement for Vorbis and Theora was first added 
> to the spec, and Apple objected, we looked at the situation and 
> searched long and hard for an alternative that would address their 
> concerns.
>
> It's also worth nothing that the patent concerns expressed by Apple 
> are also shared by Microsoft [1].  So if we were to include a 
> requirement for Theora and Vorbis in the spec, when we attempt to move 
> to Last Call, the likely result would be that we would get formal 
> objections from both Apple and Microsoft, at which point would have to 
> go through this whole debate again and probably end up right back 
> where we are now.
>

You seem to think that Apple issuing a formal objection then would be a 
bad thing, when the opposite is true. If this had been the approach 
used, the decision about Theora and Vorbis would be less "the W3C has 
removed the video element" to characterize the current headlines, and 
more "Apple has formally protested the inclusion of Theora and Vorbis in 
HTML 5". It puts the onus on the correct party, and forces Apple into a 
position where it not only has to defend itself as regards to the HTML 
WG, it has to defend itself to the world.

Whoever was involved in this decision gave away the only power the HTML 
WG actually has. In doing so, they also ended up bringing the heat down 
on the W3C, when the heat should be directed at Apple. And Microsoft, 
too, if it were to formally object.

> Interestingly, this issue is also occurring in relation to Web Fonts. 
> From what I've been told, Microsoft have objected to supporting 
> TTF/OTF in support of their own EOT format, and commercial font 
> foundries are pushing for some form of DRM.  This is why they're now 
> debating the issue intensly on the www-font mailing list.  So this 
> situation certainly isn't unique to the HTMLWG.
>

I hope that the www-font group learns fron the mistakes of the HTML WG, 
and realizes it's better to have the vendors make formal objections, 
because then it makes them have to back up their decisions, not only to 
the group, but to the entire web community.

These types of objections should never occur within the boundaries of a 
email list, or back room discussion. They should be exposed, brightly to 
the world, and let the world have a chance to express its opinion, one 
way or another. Because that is the power the W3C groups have. It is the 
only power the W3C groups have.

> As for your concerns regarding the potential for features like canvas, 
> MathML or SVG being removed, I think you're blowing this way out of 
> proportion.  In fact, Microsoft already expressed their opinion that 
> having an immediate mode graphics API was a good thing [2].  However, 
> their concerns were related to the feature being out of scope of the 
> charter and whether the HTMLWG was the best place to develop it.  
> Also, since the we've had a WG decision to include it, we've heard no 
> further objections from them on the issue.

Well, frankly, we haven't heard much from Microsoft about anything, have 
we? But the company's lack of assurances only means that at any time, it 
could protest the inclusion of any one thing, such as SVG in HTML, and 
based on this principle of one vendor/one vote, the item is gone. Either 
a principle is applied consistently, across the specification and to all 
of the five vendors, or it is not applied consistently, and should be 
challenged.

The Microsoft rep is present in this emailing, and is HTML WG co-chair. 
It is fair to ask, in light of one vendor/one vote, will Microsoft be 
implementing the canvas element? MathML? SVG in HTML?

Will Microsoft be supporting an XML serialization of HTML 5 (XHTML 5)?

Now, how do we interpret a non-answer if such occurs? In light of one 
vendor/one vote?
>
> I'm also not aware of them expressing any concern over the inclusion 
> of MathML and SVG, and even though I'm not aware of them explicitly 
> saying they will support it, we have no reason to assume they won't.  
> In fact, I'm not particularly surprised that they haven't said they 
> will support it, as they, like many companies, tend to keep 
> information about future products confidential.
>
I am sorry but keeping future products confidential is not a valid 
argument when it comes to support for open specifications. If this is 
true, then all five vendors should excuse themselves from further 
participation in this process, because their participation could hinder 
the development of a specification that may run counter to their own 
proprietary interests.

Saying that a company will support something such as SVG at some future 
time isn't giving away any proprietary secrets. This is no different 
than a company saying they will support HTML 5, and you don't have any 
quibbles about asking for this from the five.

> Regading your concerns about XHTML, I've heard Chris Wilson on 
> numerous occasions say that they are in favour of eventually 
> supporting XHTML [3].  Although I have no information about when that 
> will happen, I don't think we should be too concerned about them 
> turning around and refusing to support it.
>
> [1] http://lists.w3.org/Archives/Public/public-html/2007Apr/0255.html
> [2] http://www.w3.org/2002/09/wbs/40318/req-gapi-canvas/results
> [3] http://blogs.msdn.com/ie/archive/2005/09/15/467901.aspx
>

But you're not basing this on _fact_, and we've seen how important 
facts, and data are, when it comes to determining what is, or is not in 
the HTML 5 specification. If we are to be consistent, then we need to 
apply the same drive for facts and data across the board, with all 
decisions--not just those where one vendor has an interest, or concern.

We do not know, for a fact, that Microsoft supports XHTML, or SVG, or 
MathML, or Canvas, or most other elements in the HTML 5 specification. 
What we do have is data, data in the form of current support in current 
Microsoft tools. And according to the data we can gather, both from the 
past, and currently, these HTML 5 components will not be supported by 
Microsoft. Therefore we have to assume support for such will continue to 
be broken across a significant portion of the user community. Based on 
the principles underlying the decisions made about Theora and Vorbis, 
and about @summary, (and seemingly cite and others that I've been able 
to discover), we must either obtain facts from Microsoft (a statement of 
support or non-support, one way or another), or we will have to let the 
data form the basis of our decisions, and yank all of these items from 
the spec (though it would pain me greatly to see such mature, and 
useful, innovations go).

To be consistent, we have to do this. Because the specification that 
will lead the way to the future of the web must, above all, be 
consistent. Otherwise, it's just so many words on a web page, and with 
the release of HTML 5, W3C will have left the web in a rudderless state.

Either that, or we look again to the "rules" being used to defend HTML 5 
decisions, and acknowledge, and correct, their inconsistencies.

Shelley

Received on Thursday, 9 July 2009 13:44:02 UTC