W3C home > Mailing lists > Public > public-device-apis@w3.org > February 2011

The Wider Web (was: Rechartering Device APIs & Policy Working Group)

From: Robin Berjon <robin@berjon.com>
Date: Mon, 7 Feb 2011 13:42:53 +0100
Cc: Dominique Hazael-Massieux <dom@w3.org>, public-device-apis <public-device-apis@w3.org>
Message-Id: <3E294A8C-703E-4DA3-A8D6-2C2D2AFC20BE@berjon.com>
To: Bryan Sullivan <blsaws@gmail.com>

On Feb 2, 2011, at 17:04 , Bryan Sullivan wrote:
> Active work in W3C depends upon resources, and we did not expect our focus on meeting market needs with an evolution of the JIL and BONDI specs to create the environment in which DAP could veer off-course, but that is what has happened. Focusing on the market is exactly what OMTP did in BONDI (with commercial implementations in the market) and WAC has done with WAC 1.0 (also in the market) and WAC 2.0. Our focus on serving the market's needs, *now*, limited our resources for DAP in the last year.

I think that there are several underlying assumptions here that need to be surfaced.

First, you mention several times a focus on "the market". By that I believe that you mean on "the *mobile* market". The mobile market is huge, and sexy, and I love it, but no matter how huge or sexy or loved it is still just a subset of the Web. A large, important subset, but a subset nevertheless. OMTP did a great job in developing mobile-oriented solutions and I hope that WAC meets with success in continuing that work.

But you seem to imply that DAP's mission was to continue that work, and somehow rubber-stamp if not its specifics, at least its general design decisions. I repeatedly stated that that was unlikely to happen. DAP has not "veered off course", it has simply been trying to address the needs and requirements of its full constituency  the complete Web  and not just one subset of it. That may not be the idea that you had in mind, but that doesn't put the group off charter.

If this group  or any other  were to specify a solution that were unpalatable to the mobile industry (be it for technical, economic, or political reasons, at the end of the day it doesn't matter) you would oppose it. And you'd be very much right to do so. This universality cuts both ways though: solutions that don't work outside of the mobile industry  for whatever pragmatic reason  just can't fly.

Designing APIs for the items we have on our charter is child's work. Designing them so that they can be used across the Web is the hard part. Taking vertical solutions and claiming they work everywhere doesn't work  it has to actually be true. Artificially driving a vertical solution to Recommendation just creates another piece of paper on an already large pile. It won't get adoption, it won't be Web technology.

Thankfully, through the hard work of those who have contributed, we have found ways of making these APIs work globally. We have APIs that are not only device-independent but also work the same in multiple security contexts. The added value in terms of library reuse and integration of disparate pieces of the system should be obvious.

> We also supported Web browser vendor participation by accommodating (with clearly expressed reservations) their splitting of the APIs in the "read" vs "write" (based upon the claimed inability to express the write function in their UI paradigms). 

That is a gross mischaracterisation of the group's history. No one has "accommodated" the "browser vendors". There isn't a "claimed inability" to express this or that in "their" UI paradigms. This is not about browser vendors  this is about designing APIs for the Web. In fact, much of what you write above  once removed the distortion  are based on decisions made from the input of people who aren't browser vendors.

We define technology inside a context. This context is larger than mobile. You may be able to enforce a given approach in the mobile industry and that's fine. You may *believe* that the same solution could be applied in other contexts, but that only matters if it's actually the case. If anything prevents it  technical, economic, political  then it's moot. This isn't about browsers  it's about everywhere. As it happens, everywhere includes browsers. Yes, that means limitations. Those limitations are facts  not "claims". Wishing them away won't do anything. Ignoring them will just lead to silo technology.

Let me ask a question: what motivated you to support this work in W3C? I can only presume that you hoped to see broad support for Web-wide technology instead of mobile-only solutions? And further, that that would require consensus across multiple industries, not just one?

> These accommodations may have been interpreted as a sign that a Web browser centric design pattern would be adequate (though it will not be).

Again, this is a very strange claim to make. Interpreted by whom? There is nothing browser-centric about the designs we have adopted  they simply take browsers into account as a very major component of the Web. Again, that involves limitations, and again, we've found interesting solutions to make this happen anyway.

If we designed a solution to take battery life into account, would you call it mobile-centric? Would someone suggesting that you should "just use bigger batteries" or "just deploy induction charging systems worldwide" strike you as having found a good solution?

> Thus in the last year we have seen significant erosion of the design of the DAP APIs relevant to the original vision of the group (as noted above).

Again, I am unsure about how you can see that as having been the group's original vision when in fact it contradicts the W3C's mission of working everywhere.

> I will reach out to the numerous web runtime (WRT) vendors who will be implementing the WAC specs to provide W3C firm evidence of market support for the API functionality design and security/privacy concept of WAC.

That will be useful no matter what, and I thank you in advance for making this information available. That being said, I suspect that in this instance again when you say "market" you mean "mobile market". Is there any chance that you could find similar support across more industries?

> I ask that you also provide the specific feedback that you received from vendors (presumably desktop Web browser vendors) which has resulted in such a shift in the DAP charter as you propose. Or at least, I hope these vendors can provide comments on the DAP list which substantiate their positions (including what market segments / use cases they are basing those positions on). 

I do not think that I should share comments made in private but I certainly join you in hoping that we receive broad comments here. I will however say this:

   The request to define the scope of our work better than it was previously has come from several members (in private discussion) who have expressed concern that the fuzzy scope meant that they did not know what intellectual property would be committed to the group if they joined. Irrespective of what one may think of software patents and IP, that's how the game is played and I think that this request is only reasonable.

   The addition of privacy is actually a bugfix: everyone initially thought that it was part of the charter, and was surprised when it wasn't. We however proceeded as if it had been there all along.

   Most of the other changes reflect the way in which the group has actually operated, and correspond to resolutions made in quorate meetings. The fact that external feedback goes in the same direction is encouraging, but I can only point out that we did most of these changes internally, as a group.

> There is a wider Web beyond the browser, and our vision for DAP was to develop specifications that can serve it.

To serve *all* of it, and not just specific vertical interests, yes. And we're not serving a Web "beyond the browser", we're serving the whole darn Web, warts, history, and all.

Robin Berjon - http://berjon.com/
Received on Monday, 7 February 2011 12:43:23 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:47 UTC