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

I can also say re "Taking vertical solutions and claiming they work 
everywhere doesn't work — it has to actually be true" that forcing solutions 
that only work in horizontal domains onto every market that intersects that 
horizontal domain doesn't work either. Either the depth of the horizontal 
domain needs to be expanded ("wider" in my expression), or we face the 
unenviable situation for developers that they will have to support two 
different API design and security models. We owe it to the market (yes I do 
like that word - it pays my bills) to do our best to address this challenge, 
and not to take the easy way out (for us) of running to our separate corners 
and reassuring ourselves that at least we are serving the most important 
part of the market.

I think the shifts in DAP's focus, especially in the last year, speak for 
themselves re adherence to the course.

We should be careful of claiming what will or "won't be Web technology". 
Adoption defines what "will be", and I would place very strong bets on the 
adoption of the same API design and security design model submitted to DAP 
as BONDI.

We joined DAP with the same objective as joining the MWI and Webapps - to 
aid in the development of standards for context-adaptive Web technology. We 
do have a primary context in mind (mobile), just as desktop browser vendors 
do (general purpose computing platforms). Saying that any Web technology has 
to have no more specialization that is necessary for use in a general 
purpose computing platform clearly draws a line between market segments. IMO 
that is an unnecessary and unhelpful distinction, as diversity is inherent, 
and adaptability to diversity is achievable.

--------------------------------------------------
From: "Robin Berjon" <robin@berjon.com>
Sent: Monday, February 07, 2011 4:42 AM
To: "Bryan Sullivan" <blsaws@gmail.com>
Cc: "Dominique Hazael-Massieux" <dom@w3.org>; "public-device-apis" 
<public-device-apis@w3.org>
Subject: The Wider Web (was: Rechartering Device APIs & Policy Working 
Group)

> Hi,
>
> 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 Wednesday, 9 February 2011 09:15:01 UTC