DAP rechartering

I commented on the call that if the group decides to change the approach
to discrete system information property access and sensors, away from
the current approach of the Sysinfo spec (an common interface through
which various properties can be accessed), I suggest rather than try to
evolve the current spec in that direction, DAP start new with new
spec(s) for the discrete purposes. This would allow as Richard proposed,
that the implementers be able to focus on discrete properties/sensors as
they become needed and implementable. It will also help avoid the
potential fragmentation with other API designs that do exist in the
market, which are more aligned with the intent of the Sysinfo design as
it stands today, and are supported by a number of implementations
already. 

 

This is in general an approach I think DAP should take with the APIs in
its charter. Where it has not completed work on APIs that were in fairly
complete form when originally submitted as input to DAP two years ago,
that indicates to me a difference in vision and API design approach
which may not easily be resolved at this point. DAP should not continue
to struggle with what may be a working approach with limited success
potential, i.e. trying to merge to significantly different visions for
APIs into a single set of specs. If W3C was able to complete these
specs, in the end they probably would just confuse the market and cause
fragmentation impacting vendors which have to implement two APIs for the
same purpose (with different widely models for API design, user
interaction necessity, and security/privacy). 

 

Thus I think DAP should drop those APIs it has not finished and focus on
new work that does not conflict with the other work in these areas which
has continued in the market in the last two years, and which is now
widely supported, and likely to be brought to W3C for standardization in
the near future. This sequence should be familiar to W3C members: market
initiative and W3C response (group/work initiation), with
implementations continuing to be developed, and eventually driving W3C
to refocus on supporting the actual implementations in the market. DAP
has the opportunity in this rechartering phase to recognize and respond
to that need for realignment in the work that W3C is doing in this area.

 

We still firmly support the API scope in the original DAP charter, but I
question if it's effective to keep struggling to address them under
DAP's new charter. Thus I would rather see DAP focus on a unique API
scope, to avoid market fragmentation.

 

Thanks, 

Bryan Sullivan | AT&T